 Microsoft FORTRAN Compiler
 =============================================================================


 1. Graphics for FORTRAN

 Product Version(s): 3.3x 4.00 4.01 4.10 5.00
 Operating System:   MS-DOS
 Flags: ENDUSER | B_QuickBAS
 Last Modified: 29-AUG-1989    ArticleIdent: Q26943

 Question:

 I would like to produce graphics output with my FORTRAN programs. Can
 you recommend any graphics packages and/or libraries that I can use
 with FORTRAN?

 Response:

 Note: FORTRAN Version 5.00 has support for graphics. The following
 response includes only FORTRAN 4.10 and earlier.

 We do not currently provide graphics libraries for FORTRAN. However,
 since FORTRAN supports interlanguage calling between our other
 languages, we suggest you try our new QuickC compiler package. QuickC
 offers a run-time library of over 300 functions, including graphics
 routines and cursor control.

 The graphics package supports CGA, EGA, and VGA. Other QuickC run-time
 facilities include random number generation, string manipulation, and
 DOS function calling. By using QuickC, you not only have access to the
 run-time library package, you also have the luxury of a whole new
 language to program with. QuickC provides an integrated programming
 environment complete with editor, compiler, and a source-level
 debugger. With QuickC, you can write routines that can be called from
 FORTRAN or write programs that can call your FORTRAN subroutines.
 QuickC can provide the kind of flexibility that is not easily
 duplicated in FORTRAN.

 Our QuickBASIC compiler package also offers graphics support. The
 facilities provided mirror the ones available in QuickC but in a
 format that is consistent with the BASIC language.

 You can also call assembly-language routines written by you or
 third-party vendors. The bluebook of assembly-language routines for
 the IBM PC and XT by Christopher L. Morgan contains graphics and
 cursor positioning routines that may be called by your program.
 However, it should be noted that these routines were written
 specifically for the IBM and may have to be altered somewhat to run on
 IBM compatibles.

 Another option is to use the ANSI escape sequences to affect cursor
 movement and screen clearing. These have limited uses in producing
 graphics routines. Contact Microsoft Product Support Services for more
 information on ANSI escape sequences by calling (206) 454-2030.

 In addition to these, a "Language Support Directory" is provided with
 each copy of FORTRAN. This booklet lists several vendors who provide
 graphics libraries (and other libraries such as communications
 packages) compatible with FORTRAN.


 2. The Following Code Caused Error F2124 Code Generation Error

 Product Version(s): 4.01
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist4.01 fixlist5.0
 Last Modified: 14-JUL-1989    ArticleIdent: Q26944

 Problem:
    The following code will produce error F2124, code generation error:

         SUBROUTINE SUB
 C       IMPLICIT REAL*8 (A-H,O-Y)
         COMPLEX*16 SI,IB0,IB0P,IB1,IB1P,IBES0(3002),IBES1(3002)
         COMMON /CMN2/IBES0,IBES1,KBES0
 C
         IB0=0.5D1*IBES0(L1)
         IB0P=0.25D1*(IBES0(L0)+SI*IBES0(L1)+IBES0(L2))
         IB1=0.5D1*IBES1(L1)
         IB1P=0.25D1*(IBES1(L0)+SI*IBSE1(L1)+IBES1(L2))
 C
         RETURN
         END

 Response:
    This is a known problem in Version 4.01.
    Microsoft is researching this problem and will post new information
 as it becomes available.
    The workaround is to use the /Od switch or comment out the common
 statement.


 3. FORTRAN: Internal Compiler Error: mactab.c 1.34, Line 662

 Product Version(s): 4.01
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist4.01 buglist4.10 fixlist5.00
 Last Modified: 16-JUN-1989    ArticleIdent: Q26945

 The code below generates the following internal compiler error:

 code.for
 code.for(15) : fatal error F1001: Internal Compiler Error
                 (compiler file '@(#)mactab.c:1.34', line 662)
                 Contact Microsoft Technical Support

 The code is as follows:

         SUBROUTINE SUB
         COMPLEX*16 SI,IB0,IB0P,IB1,IB1P,B1,B2,IBES0(3002),IBES1(3002)
         COMMON /CMN2/IBES0,IBES1,KBES0
 C
         IB0=0.5D1*IBES0(L1)
         B1=IBES0(L0)+SI*IBES0(L1)+IBES0(L2)
         IB0P=0.25D1*B1
         IB1=0.5D1*IBES1(L1)
         B2=IBES1(L0)+SI*IBSE1(L1)+IBES1(L2)
         IB1P=0.25D1*B2
 C
         RETURN
         END

 The workaround is to disable optimization with the /Od switch or to
 remove the common block statement.

 Microsoft has confirmed this to be a problem in Versions 4.01 and
 4.10. This problem was corrected in Version 5.00.


 4. FORTRAN: Internal Compiler Error: p3io.c 193, Line 813

 Product Version(s): 4.01 4.10 | 4.10
 Operating System:   MS-DOS    | OS/2
 Flags: ENDUSER | buglist4.00 buglist4.01 buglist4.10 fixlist5.00
 Last Modified: 16-JUN-1989    ArticleIdent: Q26968

 The code below causes the following internal compiler error, but gives
 no line number for the source code that caused the error:

 fatal error F1001: Internal Compiler Error
                 (compiler file '@(#)p3io.c:1.93', line 813)
                 Contact Microsoft Technical Support

 Function names are global and do not need to be passed to other
 functions. Microsoft has confirmed this to be a problem with Versions
 4.01 and 4.10 of the FORTRAN compiler. This problem was corrected in
 Version 5.00.

 There are two workarounds, as follows:

 1. In the first workaround, do the following:

    a. Remove "fx" when calling "simp()".

    b. Remove "f" in the simp() function declaration.

    c. Rename the call to "fx()" in simp() from "f()" to fx().

 2. In the second workaround, comment out the print statement.

 The code is as follows:

 program int (intput,output)
     integer n
     real a,b,simp
     external fx
     read *,a,b,n
     print *,'int = ',simp (a,b,n,fx)
     end

     real function fx (x)
     real x
     fx=x*x
     end

     real function simp(a,b,n,f)
     integer j,n
     real a,b,c,h,sum
     c=2.0
         do 5 j=1,2*n-1
          c=6.0 - c
          sum=sum+c*f(a+j*h)
 5        continue
     simp=sum*h/3
     end


 5. Blank Character Before "O"

 Product Version(s): 3.31
 Operating System:   MS-DOS
 Flags: ENDUSER | TAR54911 docerr
 Last Modified: 19-SEP-1988    ArticleIdent: Q11753

 Problem:

 The following program on Page 110 of the "Microsoft FORTRAN Compiler
 Reference" manual does not work properly; the first character of the
 write statement is lost:

    program wrt
    character*8 fname
    write(*,'(A\)') 'Output filename?:'
    read(*,'(A)') fname
    end

 Response:

 The document is incorrect. The example should be corrected by
 inserting a blank character before the "O" in "Output filename?" to
 reflect the correct behavior.

 It is important to remember that the first character of an output
 statement that uses unit 0, unit *, or the files PRN, LPT1, or CON is
 not printed but instead is interpreted as a carriage control
 character.


 6. No Error when Giving INTEGER*1 an Out-of-Range Value

 Product Version(s): 4.01
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist4.01
 Last Modified:  1-JUN-1988    ArticleIdent: Q26969

    When an INTEGER*1 item in the range -127 to 127 is assigned a value
 that exceeds the legal size-limits, no error message is returned.
 Execution continues, but with unpredictable results. The error message
 should be "F6100: INTEGER overflow on input."
    This is a known problem in Version 4.01.
    Microsoft is researching this problem and will post new information
 as it becomes available.


 7. Random Number Generation in FORTRAN

 Product Version(s): 4.00 4.01 4.10 5.00
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 11-JUL-1990    ArticleIdent: Q27211

 A random number generator was added with Microsoft FORTRAN version
 5.00. It is documented on Pages 272-273 of the "Microsoft FORTRAN
 Reference" for version 5.00.

 There is no function for random number generation in previous versions
 of Microsoft FORTRAN. However, there are at least two ways to generate
 a random number with FORTRAN versions 4.00, 4.01, and 4.10.

 The sample program DEMORAN.FOR on the Utilities and Source Code Disk
 (Disk 3 of 6) for versions 4.00 and 4.10 and on the Setup Disk for
 version 4.10 demonstrates a uniform random-number generator. It is
 documented in the comments at the beginning of the file.

 Another way to get a random number is to make use of the
 interlanguage capability of Microsoft FORTRAN. A call to QuickC is an
 easy way to get access to Rand and other C run-time library routines
 (as well as to the QuickC compiler, editor, and debugger, and other
 features, such as graphics routines).


 8. Fatal Error F1910 Unrecognized Option

 Product Version(s): 4.01
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 21-JUL-1988    ArticleIdent: Q27129

    The most common reasons for fatal error F1910, "unrecognized
 option," are an inability to open temporary files or an incorrect
 version of COMMAND.COM. Verify that "VER" and "COMMAND" both return
 the same version. If "VER" and "COMMAND" both return the same version,
 the error is caused by a problem with opening temporary files. One of
 the following could be the cause of this problem:

    1. The temporary variable is set incorrectly. The TMP variable must
 be set as follows:

    SET TMP=c:\myfullpath\mydir

    The line can have no extra spaces, and there must be a carriage
 return immediately following the last character. Retype this line at
 the DOS prompt if you are unsure about its syntax. The specified
 subdirectory must exist in the path as given.
    2. There is not enough room on the disk to store temporary files.
    3. There are not enough file handles to open temporary files. Make
 sure that the following two lines are in your CONFIG.SYS and that all
 terminate-and-stay-resident (TSR) programs are removed from the
 system:

    files=20
    buffers=20


 9. Incorrect Floating Point Representation

 Product Version(s): 3.31
 Operating System:   MS-DOS
 Flags: ENDUSER | TAR55281 buglist3.31 fixlist4.00
 Last Modified: 15-APR-1988    ArticleIdent: Q11835

 Problem:
    The following program gives the result 0,0 instead of 0,6:

    $storage:2
    program asst
    real coord(2)
    integer acc(2)
    integer i
    i=2
    coord(i)=acc(i)
    acc(i)=acc(i)+6
    write(*,*) acc
    end

 Response:
    Microsoft confirmed this to be a problem in Version 3.31 of the
 FORTRAN compiler. The problem was corrected in Version 4.00.
    A workaround is to add the $NOFLOATCALLS metacommand.


 10. FORTRAN Setup on One 5.25" and One 3.5" Floppy Drive

 Product Version(s): 4.01
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified:  8-MAR-1988    ArticleIdent: Q27501

 Question:
    I want to set up FORTRAN on my two-floppy system, but I have one
 drive that is 5.25 inch and one that is 3.5 inch. How can I do this?

 Response:
    Do not use the setup program. Instead, choose the disk size on
 which you wish to install FORTRAN. Then refer to the "Microsoft
 FORTRAN Compiler User's Guide." Table 2.1 on Pages 22-23 shows the
 disk organization to follow for 5.25 inch disks and Table 2.2 on Pages
 26-27 shows the disk organization to follow for 3.5 inch disks. Copy
 the files according to the suggested configuration for your chosen
 drive. The other drive will hold your source disk.
    You will need to build the libraries yourself. Use the BUILD1.BAT
 utility and follow the guidelines in the README.DOC file.
    When running the FORTRAN compiler, expect to see the warning
 message "Command line warning D4005 : could not execute 'f2.exe';
 please insert diskette and press any key." This is an expected
 response when running from a floppy setup. Swap disks at this point
 and continue compiling.


 11. Compatibility with an 80387 Coprocessor

 Product Version(s): 4.01
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified:  9-MAR-1988    ArticleIdent: Q27502

 Question:
    Will the Microsoft FORTRAN compiler work with an 80387 math
 coprocessor?

 Response:
    You can use the coprocessor with all of our programming languages,
 but you can take advantage of it only up to the limit of the 80287
 instruction set.


 12. Cannot Trace into Program with Include File

 Product Version(s): 4.00 4.01 4.10
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 25-OCT-1988    ArticleIdent: Q27551

 Problem:

 I have an include file that contains the following declaration:

     INTEGER*2 I,J

 When I trace into this program using CodeView, the entire program
 executes and I cannot set any break points. I am compiling the code
 with the following switches:

    /Zi
    /Od
    /FPi
    /4Yb.

 Response:

 The problem is that the switch "/4Yb" creates its own line
 information, which conflicts with the "/Zi" CodeView information.

 To work around this problem, do not to use the "/4Yb" switch when
 viewing under CodeView.


 13. How Many Files Can You Access?

 Product Version(s): 3.20 3.30 3.31 4.00 4.01 4.10 5.00 | 4.10 5.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified: 24-JUL-1990    ArticleIdent: Q12086

 The maximum number of files that you can open using versions of
 Microsoft FORTRAN prior to version 5.00 is 15. This maximum number
 of files is a FORTRAN limitation.

 Query on the words FILE and LIMIT and FORTRAN for more information
 about increasing this limit with FORTRAN 5.00.

 There is no limit on the number of files that you can open and close
 during the run of a program. The limit applies only to the number of
 files that can be open at the same time.

 This maximum number of open files is affected by the "FILES=" variable
 set in your CONFIG.SYS file. If you set the "FILES=" variable to less
 than 20, e.g. "FILES=15", then the maximum number of open files will
 decrease. FORTRAN opens five files itself: standard input, standard
 output, standard printer, standard error, and standard auxiliary.
 Since 5 of the 20 possible file handles are used by FORTRAN, that
 leaves your program 15.

 A simple explanation of how many files can be opened is found in IBM's
 "Disk Operating System Version 3.10 Reference" Pages 4-19 through 4-21
 "FCBS (File Control Block) Command" and Pages 4-22 through 4-23 "FILES
 Command", in particular Page 4-23 in the section called "Number of
 Files Opened".

 For more technical details on file handles, see IBM's "Disk Operating
 System Technical Reference" for Version 3.10, Chapter 4 "File
 Management Notes". See especially the following sections: "Handle
 Function Calls" (Pages 4-6 through 4-7), "Special File Handles" (Page
 4-8), "Number of Open Files Allowed" (Page 4-12), and "Restrictions on
 Handle Usage" (Page 4-13).


 14. INQUIRE Does Not Look Along APPEND File List

 Product Version(s): 4.00 4.01
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist4.00 buglist4.01 fixlist4.10
 Last Modified: 27-JUN-1988    ArticleIdent: Q27660

    The following program requires a file named A.A. The DOS command
 APPEND should allow you to list the directories in which you have
 files; thus, you do not have to specify the fully qualified path name
 of the file in your program. However, the INQUIRE statement does not
 seem to be searching this APPEND list.

          CHARACTER*20 FNAME
          LOGICAL FOUND
          DATA FNAME/'A.A'/
    C
          FOUND=.FALSE.
          INQUIRE (FILE=FNAME,EXIST=FOUND)
          WRITE(*,*) ' FILE= ',FNAME,'   EXIST= ',FOUND
    6     CONTINUE
          STOP
          END

    Microsoft has confirmed this to be a problem with the FORTRAN
 Compiler Versions 4.00 and 4.01.
    Microsoft is researching this problem and will post new information
 as it becomes available.


 15. INQUIRE Statement Filename Length

 Product Version(s): 3.30
 Operating System:   MS-DOS
 Flags: ENDUSER | TAR57139 docerr
 Last Modified: 13-JAN-1989    ArticleIdent: Q12130

 Page 105 of the "Microsoft FORTRAN Compiler Language Reference" should
 state the following:

 The INQUIRE statement does not handle filenames longer than 31
 characters.


 16. File I/O Errors

 Product Version(s): 3.30
 Operating System:   MS-DOS
 Flags: ENDUSER | TAR57193 docerr
 Last Modified:  7-SEP-1988    ArticleIdent: Q12129

 On Page 252 of the "Microsoft FORTRAN Compiler User's Guide," the File
 I/O Errors should read as follows:

 1270 Console I/O error
 1271 User tried to rewind CON (i.e. the terminal) or USER
 1272 File I/O error after previous error


 17. FL Environment Variable Appears to Fail

 Product Version(s): 4.10   | 4.10
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | docerr langerr
 Last Modified: 18-AUG-1988    ArticleIdent: Q27557

    If you set the FL environment variable exactly the way it is set in
 the two examples on Pages 10 and 12 of the "FORTRAN 4.10 Update," it
 will not affect compiling.
    The examples on Pages 10 and 12 of the update are incorrect; spaces
 are not allowed around the equal sign. The corrected example should
 state "SET FL=/Lr" with no spaces around the equal sign. However,
 spaces should be used between consecutive options.
 "SET FL=/Lr /FPi /Od" is correct.
    The /LINK option also must be given in all lowercase letters, as
 /link (the FL command line is case sensitive). Please note that the /I
 option also is incorrect; the correct option should be /INF.


 18. Using the C 5.0 Preprocessor

 Product Version(s): 4.01 4.10
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 12-MAY-1988    ArticleIdent: Q29595

 Problem:
    I am using the C 5.0 preprocessor before invoking the FL command to
 define long names (around 30 char) to something shorter for use in
 FORTRAN. However, the preprocessor is inserting blanks before comment
 lines; thus they are no longer comments in the eyes of the FORTRAN
 compiler. The manuals say it is legal to use the preprocessor. What is
 happening to the code?

 Response:
    The procedure you describe will not work. The C preprocessor is not
 a text processor and will not do what you are trying accomplish. The
 following are two alternate methods:

    1. Use the ALIAS keyword. For example:

         interface to subroutine _clearscreen[C, ALIAS =
  '_cls'] (area)

         /*  The underscore must be there in both places.  */

    2. Use the $NOTRUNCATE metacommand to set variable names to 31
 significant characters.


 19. Internal Compiler Error: grammar.c, Line 91 and FORTRAN 4.10

 Product Version(s): 4.00 4.01 4.10
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist4.10 fixlist5.00
 Last Modified: 24-JUL-1990    ArticleIdent: Q27559

 Problem:

 The code below produces the following error:

 COMPERR.FOR(9) : fatal error F1001: Internal Compiler Error
                 (compiler file '../grammar.c', line 91)
                 Contact Microsoft Technical Support

 Microsoft has confirmed this to be a problem with the FORTRAN compiler
 Version 4.10. This problem was corrected in Version 5.00.

 If you are using Version 4.10, the only workaround is to disable loop
 optimization by using /Od or /Odct.

 The code is as follows:

         SUBROUTINE CPII1(ID,JD,IXS,IXE,IYS,IYE,JERR)
         IMPLICIT INTEGER*2 (I-N)
         DIMENSION ID(IXS:IXE,IYS:IYE),JD(IXS:IXE,IYS:IYE)
         DO 100 IL=IYS,IYE
         DO 100 KM=IXS,IXE
         JD(KM,IL)=ID(KM,IL)
   100   CONTINUE
         RETURN
         END
 C----------------------------------------------------------------------
         SUBROUTINE BKCUT2(ID,IBK16,IBK8,IFX,IFY,IBX,IBY,IB,IABK,JERR)
         IMPLICIT INTEGER*2 (I-N)
         DIMENSION ID(IFX,IFY),IBK16(IFX/IBX,IFY/IBY),
      A            IBK8(IFX/IBX,IFY/IBY,IB,IB)

         DO 1000 KM=1,IFX/IBX
         DO 1000 IL=1,IFY/IBY

         DO 900 KM1=1,IB
         DO 900 IL1=1,IB
         IF(IBK8(KM,IL,KM1,IL1).EQ.0) GO TO 900
         DO 800 KM2=1,IBX/IB
         DO 800 IL2=1,IBY/IB

         IKP=(KM-1)*IBX+(KM1-1)*(IBX/IB)+KM2
         ILP=(IL-1)*IBY+(IL1-1)*(IBY/IB)+IL2
         ID(IKP,ILP)=IABK

   800   CONTINUE
   900   CONTINUE
  1000   CONTINUE
         RETURN
         END


 20. Must Should Be May

 Product Version(s): 4.00
 Operating System:   MS-DOS
 Flags: ENDUSER | docerr
 Last Modified: 13-JAN-1989    ArticleIdent: Q19786

 On Page 9 of the "Microsoft FORTRAN 4.00 Quick Reference Guide," note
 3, the word "must" should be changed to "may."


 21. Floating-Point Exception Handling

 Product Version(s): 4.00 4.01 4.10 | 4.10
 Operating System:   MS-DOS         | OS/2
 Flags: ENDUSER |  coprocessor 8087 80187 80287 80387
 Last Modified: 30-SEP-1988    ArticleIdent: Q19807

 Question:

 How can I clear the status word? Can I set it to any value I want?
 Page 359 of the "Microsoft FORTRAN User's Guide", Appendix D states
 that the status word remains set until the user clears it.

 Response:

 The following is a routine named "clrstat", which will allow
 you to clear the status word. Use this routine at your own
 risk, i.e., we do not support this routine.

 In both Versions 3.31 and 4.00, you cannot change the status word.
 Once it is set to a value (perhaps by a divide-by-zero error), the
 status remains at that value. Even by using assembly language, you
 only are allowed to clear the status word; you cannot set it to a
 specific value.

 The math run time does not allow you to clear the status due to the
 coupling of the invalid exception and NDP stack overflow conditions on
 the chip; the same exception is raised for both conditions. The
 clearing of the status word is prohibited because, due to the order in
 which the evaluation is done, you can inadvertently clear an invalid
 exception before the exception handler can access it.

 The following is a short FORTRAN program that first generates a
 divide-by-zero error, then does a valid calculation, followed by an
 assembly-language subroutine that only clears the status word:

    integer*2 sswrqq
    call lcwrqq (4927)
    call val1 (x,y) 100 continue
    z = x/y
    irep = sswrqq()
    write (*,*) 'status=',irep
    if (irep .eq. 4) then
    write (*,*) 'divide by zero'
    call clrstat
    endif
    if (irep .eq. 0) stop
    call val2 (x,y)
    go to 100
    end
    subroutine val1 (x,y)
    x = 1.0
    y = 0.0
    end
    subroutine val2 (x,y)
    x = 5.0
    y = 2.0
    end

    TITLE clrstat

    .8087 CLRSTAT_TEXT SEGMENT BYTE PUBLIC 'CODE' CLRSTAT_TEXT ENDS
    ASSUME CS: CLRSTAT_TEXT EXTRN __acrtused:ABS CLRSTAT_TEXT SEGMENT
    PUBLIC CLRSTA CLRSTA PROC FAR
    push bp
    mov bp,sp
    fclex
    fwait
    pop bp
    ret CLRSTA ENDP CLRSTAT_TEXT ENDS END


 22. Internal Compiler Error: loop.c 1.87, Line 836

 Product Version(s): 4.00
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist4.00 fixlist4.01
 Last Modified:  1-JUN-1988    ArticleIdent: Q19941

 Problem:
    I am getting an internal compiler error on loop.c:1.87 Line 836.

 Response:
    This is a known problem in Version 4.00.
    This problem was corrected in Version 4.01.
    An error in loop.c probably indicates that the problem involves
 loop optimization. You may be able to work around the problem by
 separately compiling the routine specifying either -Od (optimization
 disabled) or -Odct (no loop optimization, but still perform common
 subexpression elimination and optimization for time) options.


 23. Compaq 386 Floating Point Error

 Product Version(s): 4.00
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified:  4-MAR-1988    ArticleIdent: Q19948

 Problem:
    When running in real mode and using a 80287, a floating
 point exception occurs (such as divide by zero) and the CX
 register is destroyed.

 Response:
    The problem can occur with any product that accesses the
 80287 directly. Compaq is aware of the problem and has a
 solution available. If you are having such a problem,
 contact the Compaq hotline directly for more information.
    In FORTRAN, the problem may show itself by a program
 hanging in an infinite loop or (even worse) having loops
 terminate early. If you are using FORTRAN Version 4.0, you
 may be able to avert the problem by recompiling to disable
 loop optimization (either -Od or -Odct).
    Note that if you try to demonstrate this problem with
 CodeView, you cannot simply go to the offending instruction
 and then single step; you will not see the problem. You
 must set a breakpoint several instructions past the "bad"
 instruction.
    If you are using FORTRAN or C, you can determine if they
 have the problem by one of two methods:

    1. Re-compile with -FPa compiler option. If doing this
 action allows your program to run, contact COMPAQ.
    2. Mask (disable) the floating point exceptions. This is
 not the solution of choice since there are certain
 exceptions (denormal and invalid) that you are not
 permitted to mask.


 24. Run-Time Error F6419

 Product Version(s): 4.00
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified:  8-DEC-1987    ArticleIdent: Q19942

 Problem:
    I am getting an error F6419: illegal structure for
 unformatted file.

 Response:
    There are two likely possibilities for this error
 message:

    1. Examine the OPEN statement for the file. You may have
 tried to do an unformatted READ on a formatted file. Since
 formatted files do not contain the length information that
 is required in unformatted files, this error would occur.
    2. Do not assume that since the notion of a file being
 UNFORMATTED is part of the ANSI FORTRAN standard, such
 files created on one machine are transportable to any other
 machine. The contents of such files are nonstandard and
 completely up to the implementor. Any data files that you
 wish to transport between machines should be produced only
 by FORMATTED WRITEs.


 25. PSP and Command Line Parameters

 Product Version(s): 4.00
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified:  7-DEC-1987    ArticleIdent: Q20073

 Question:
    When running a FORTRAN program, are the command line
 parameters in the PSP (Program Segment Prefix) left intact?
 In other words, could the command line parameters be
 retrieved from the PSP by an Assembler subroutine that is
 called by an Assembler program or a FORTRAN program?

 Response:
    Yes, the command line is left intact, and the parameters
 can be obtained from an Assembler program or a FORTRAN
 program.
    The parameters can be obtained by calculating where the
 PSP is in memory from your program. The PSP is generally
 256 bytes lower in memory than the first code segment.


 26. Resulting Type from Expression Using Both Integers and Reals

 Product Version(s): 4.00 4.01 4.10
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 15-MAR-1988    ArticleIdent: Q27611

 Problem:
    My program contains expressions that use different combinations of
 REALs and INTEGERs in the following form:

 <REAL variable> = <REAL or INTEGER> ** <REAL> / <REAL or INTEGER>

    In each case, the correct result should be a REAL, but with some
 combinations the expression seems to be evaluated as an INTEGER
 (fractional portion is truncated) before it is assigned to a variable
 of type REAL.

        INTEGER*4 S2
        REAL*4 FACT(10)
        DATA S2/140/
        M = 7
        FACT(1) = 7.0 ** 2.0 / 140.0
        FACT(2) = M ** 2.0 / 140.0
        FACT(3) = 7.0 ** 2.0 / S2
        FACT(4) = 7 ** 2.0 / 140.0
        FACT(5) = 7.0 **2.0 / 140
        FACT(6) = 7 ** 2.0 / 140
 C the above is incorrectly evaluated as an integer.
        FACT(7) = M ** 2.0 / S2
 C above also incorrectly evaluated as an integer.
        WRITE (*,10) M
        WRITE (*,20) S2
        WRITE (*,*)
        WRITE (*,30) FACT(1)
        WRITE (*,*)
        WRITE (*,40) FACT(2)
        WRITE (*,*)
        WRITE (*,50) FACT(3)
        WRITE (*,*)
        WRITE (*,60) FACT(4)
        WRITE (*,*)
        WRITE (*,70) FACT(5)
        WRITE (*,*)
        WRITE (*,80) FACT(6)
        WRITE (*,*)
        WRITE (*,90) FACT(7)
 10     FORMAT (1X, 'M                  = ', I6)
 20     FORMAT (1X, 'S2                 = ', I6)
 30     FORMAT (1X, '7.0 ** 2.0 / 140.0 = ', G15.7)
 40     FORMAT (1X, 'M ** 2.0 / 140.0   = ', G15.7)
 50     FORMAT (1X, '7.0 ** 2.0 / S2    = ', G15.7)
 60     FORMAT (1X, '7 ** 2.0 / 140.0   = ', G15.7)
 70     FORMAT (1X, '7.0 ** 2.0 / 140   = ', G15.7)
 80     FORMAT (1X, '7 ** 2.0 / 140     = ', G15.7)
 90     FORMAT (1X, 'M ** 2.0 / S2      = ', G15.7)
        STOP
        END

 \.BODYTEXT
 Response:
    Microsoft has confirmed this to be a problem with the FORTRAN
 Compiler Versions 4.x. A workaround would be to convert any non-REALs
 to REALs with the intrinsic function "REAL()" to insure a REAL result.


 27. Default Option Is /Oaclt Not /Ox

 Product Version(s): 4.00 4.01 4.10 | 4.10
 Operating System:   MS-DOS         | OS/2
 Flags: ENDUSER | docerr
 Last Modified: 13-JAN-1989    ArticleIdent: Q28924

 Page 97 of the "Microsoft FORTRAN Optimizing Compiler User's Guide"
 for Versions 4.00, 4.01, and 4.10 contains documentation errors.

 In Section 3.3.15, the table near the bottom of the page incorrectly
 states the following:

 Character       Optimizing Procedure

 x            Full optimization; favors execution time (default)
 t            equivalent to x
 .
 .

 The default optimization option is /Oaclt /Gs which is equivalent to
 /Ox. Alias checking is relaxed by default. The only way to enable
 Alias checking, is to first turn off all optimization and then turn
 the specific switches back on.

 An example of turning alias checking on, when all other default
 optimization remains on, is /Odclt. Also, /Ot is not equivalent to
 /Ox, but is a subset of /Ox. The table should read as follows:

 Character Optimizing Procedure

 x               Full optimization; equivalent to /Oaclt /Gs
 t               favors execution time
 .
 .


 28. Error Running Library Manager

 Product Version(s): 4.00 4.01
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 12-MAY-1988    ArticleIdent: Q20053

 Question:
    What should I do when I get "error trying to run library manager"?

 Response:
    You should do the following:

    1. Make sure the directory LIB.EXE is in your PATH.
    2. If you still get the error message, then rename your
 AUTOEXEC.BAT file, reboot, and set PATH= to the directory LIB.EXE is
 in. Booting without an AUTOEXEC.BAT file will empty your environment.
 Setup should not be sensitive to how much is in your environment.
 However, we have found that emptying the environment causes the
 problem to disappear. Microsoft is aware of this problem and will post
 new information as it becomes available.
    3. If you continue to get the error message, terminate-and-stay
 resident programs may interfere with Setup, so check to see if you
 have any installed, and if you do, remove them.
    4. If methods 1, 2, and 3 above fail to solve the problem, the
 workaround is to build the libraries manually. If you have FORTRAN
 Version 4.01, you can use BUILD1.BAT. Information for this is in the
 README.DOC file. If you have Version 4.00 or Version 4.01, you can
 build them by running Setup with the /n option ("Setup /n"). The /n
 option allows you to run through Setup without Setup performing any
 installations. The /n option is meant to be used to familiarize you
 with the installation procedure. Since the /n option does not do any
 installations, it does not need to find LIB.EXE; the /n option runs
 its course and tells you what it is doing as it goes. Therefore, you
 can copy the commands the /n option uses to build the libraries, and
 then manually use LIB.EXE to delete and combine the appropriate
 modules to build your library.


 29. How FORTRAN Stores Two-Dimensional Arrays in Memory

 Product Version(s): 4.0 4.01 4.1 | 4.10
 Operating System:   MS-DOS       | OS/2
 Flags: ENDUSER |
 Last Modified: 19-APR-1988    ArticleIdent: Q27780

 Question:
    How does FORTRAN store a two-dimensional array in memory? I know
 that C actually stores two-dimensional arrays as one-dimensional row
 arrays. Does FORTRAN use the same convention for array storage?

 Response:
    No, FORTRAN is different from languages such as C and Pascal in
 this respect. Although array elements are referenced in row major
 notation, i.e., (row, column), just as in C or Pascal, FORTRAN stores
 two-dimensional arrays as one-dimensional column arrays.
    For example, in C, a two-dimensional array with three rows and four
 columns will be stored in memory in the following sequence:

   (1,1),(1,2),(1,3),(1,4),(2,1),(2,2),(2,3),(2,4),(3,1),(3,2),(3,3),(3,4)

    However, FORTRAN will store the same array in the following
 sequence:

   (1,1),(2,1),(3,1),(1,2),(2,2),(3,2),(1,3),(2,3),(3,3),(1,4),(2,4),(3,4)


 30. Reference in Substring

 Product Version(s): 4.00
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist4.00 fixlist4.01
 Last Modified:  1-JUN-1988    ArticleIdent: Q22142

    In the following program, the first call to SWRITE contains a
 substring reference where the upper bound is a function reference (the
 answer generated from this call should be the same as the one
 generated by the second call; both should be 16):

       CHARACTER*80 A
       A='THIS IS A STRING'
       CALL SWRITE( A(1:LLEN(A)) )
       L=LLEN(A)
       CALL SWRITE( A(1:L) )
       END
       INTEGER FUNCTION LLEN(A)
       CHARACTER*(*) A
       llen=16
       END
       SUBROUTINE SWRITE(A)
       CHARACTER*(*) A
       PRINT*,LEN(A)
       RETURN
       END

    Microsoft has confirmed this to be a problem in Version 4.00 of the
 FORTRAN compiler. This problem was corrected in Version 4.01.

    The LEN(A) is what is being sent to the first SWRITE, not the
 LLEN(A). You can work around this by doing what was done for the
 second call, as follows:

    1. Evaluate the function.
    2. Store it in an INTEGER temporary.
    3. Use the temporary in the substring expression.


 31. Error on READ

 Product Version(s): 4.00
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist4.00 fixlist4.01
 Last Modified:  1-JUN-1988    ArticleIdent: Q22158

    The following program produces run-time error "F6205: READ (dat)--
 Edit descriptor expected for CHARACTER." The data file "dat" contains
 ASCII 11.

    dimension a(2)
    open(unit=1,file='dat')
    read(1,'(A1,F1.0)') a
    write(*,*) a(1) a(2)
    end

    By substituting another "A1" for the "F1.0" or conversely, using
 two "F1.0" formats, the program works properly. Also, the program
 works properly under Version 3.31.
    Microsoft confirmed this to be a problem in Version 4.00 of the
 FORTRAN Compiler. The problem was corrected in Version 4.01.

    The error will only happen if, in the middle of an array READ, the
 FORMAT specifier indicates that the next element of the array to be
 read is of a different type (REAL in this case) than the previous one.
    There are ways to work around this, using a combination of implied
 DO lists and (if necessary) single array elements as arguments to the
 READ.
    For example, if the READ statement had used the same argument list
 as did the WRITE, i.e., a(1), a(2), the program would have worked
 normally.


 32. Rounding Errors

 Product Version(s): 4.00
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist4.00 fixlist4.01
 Last Modified:  1-JUN-1988    ArticleIdent: Q22162

 Question:
    Two rounding errors occur in Version 4.00. Is it possible to get
 more information on these errors?

 Response:
    The following program demonstrates the two rounding errors:

         x = .01
         write (*,'(1x,''x='',f5.0)') x
         x = .01
         write (*,'(1x,''x='',f9.2)') x
         end

 x=   9.         [This demonstrates Error 1]
 x=      .00     [This demonstrates Error 2]

    Microsoft confirmed this to be a problem in Version 4.00 of the
 compiler. This problem was corrected in Version 4.01.
    The following is a discussion of the two error messages:

    1. Error 1:
    Any WRITE of a quantity less than 1.0 with a FORMAT of the form
 Fn.0 may produce unexpected results. Some quantities (usually the
 larger magnitude powers of 2 such as .5, .25, and .125) will produce
 the expected 0., but most (including the powers of 2 such as .0625 and
 .03125) will not.
    2. Error 2:
    This error is a very specific case and may, in fact, only affect
 FORMATs of form Fn.2 attempting to put out the quantity .01 (which is
 represented internally as .0099999).


 33. Optimization Problem

 Product Version(s): 4.00
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist4.00 fixlist4.01
 Last Modified:  1-JUN-1988    ArticleIdent: Q22163

    This problem concerns moving blocks of code to improve program
 efficiency (code motion). In this program, the block includes the
 three statements starting at statement number 10 and ending at the IF
 statement.
    Compiled with the default ($STORAGE:4), the program works properly
 but no code motion takes place (even though the compiler will always
 try to do code motion unless -Od or -Zi is used). If -4I2 or
 $STORAGE:2 is used, the block is moved just before the 9999 continue
 statement.
    The -4I2 version does not work because the compiler failed to
 generate a JMP to the code that it moved.

    The following program:

       WRITE (*,*) 'THIS IS SUPPOSED TO PRINT OUT FIRST'
       IQ=1
    10 CALL SUB1(IQ)
       WRITE(*,*) 'THIS IS SUPPOSED TO PRINT OUT SECOND'
       IF (IQ.EQ.0) GOTO 9999
       WRITE (*,*) 'THIS SHOULD NOT PRINT AT ALL'
       GOTO 10
  9999 continue
       END
       subroutine sub1 (j)
       j = 0
       end

 Should print out the following two lines:

 THIS IS SUPPOSED TO PRINT OUT FIRST
 THIS IS SUPPOSED TO PRINT OUT SECOND

 If it is compiled with -4I2, it prints the following:

 THIS IS SUPPOSED TO PRINT OUT FIRST
 THIS SHOULD NOT PRINT AT ALL
 THIS IS SUPPOSED TO PRINT OUT SECOND

    This is a known problem in Version 4.00.
    This problem was corrected in Version 4.01.


 34. Example on Page 86, 87 of Programming Guide Is Incorrect

 Product Version(s): 4.01
 Operating System:   MS-DOS
 Flags: ENDUSER | docerr
 Last Modified:  7-SEP-1988    ArticleIdent: Q27662

 Question:

 I typed in the FORTRAN assembler mixed-language programming example on
 Pages 86 and 87 of the "Microsoft Macro Assembler 5.00 Mixed-Language
 Programming Guide." When I compiled, I received more than seven
 errors. Why won't this program compile?

 Response:

 This program will not work as documented because the FORTRAN example
 is erroneous; there were two major sections omitted. First, the
 keyword FUNCTION is omitted; secondly, POWER2 must be be declared in
 the main body.

 The assembler routine is correct. The following example will compile
 and link correctly with the assembler routine:

 C   File name ftest.for
       INTERFACE TO INTEGER*2 FUNCTION POWER2(a, b)
       INTEGER*2 A, B
       END
 C
       INTEGER*2 A, B, POWER2
       A = 3
       B = 5
       WRITE(*, *) '3 * 2 to the power of 5 = ', POWER2(A, B)
       END

 After creating two OBJs, link them together with the MASM linker. The
 following is an example:

 link ftest.obj + mtest.obj;


 35. INCLUDE Files Incorrect

 Product Version(s): 4.00a
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist4.00
 Last Modified: 18-AUG-1988    ArticleIdent: Q22171

 Problem:
    The program below compiles normally if all the INCLUDE files exist
 in the same directory; however, it fails to compile if the files to be
 included exist in a subdirectory.
    The following is a program test of this problem:

 C TEST.FOR tests the include limits of 4.00

 $INCLUDE:'CCALLS.FIL'

         PROGRAM TEST

         CHARACTER*10    NAME
 $INCLUDE:'PLAN.CFD'
 $INCLUDE:'DIRECT.CFD'
 $INCLUDE:'CLIENT.CFD'
 $INCLUDE:'COLORS.CFD'
 $INCLUDE:'EMPMAS.CFD'
 $INCLUDE:'EMPLDF.CFD'
 $INCLUDE:'EMPLDD.CFD'
 $INCLUDE:'JUFFSA.CFD'
 $INCLUDE:'JOUEMP.CFD'
 $INCLUDE:'PLNTBL.CFD'
 $INCLUDE:'COLVAR.ASN'

         END

 Microsoft (R) FORTRAN Optimizing Compiler Version 4.00A
 Copyright (c) Microsoft Corp 1987. All rights reserved.

 test.for
 P1 : ` f1.exe -il D:012356 -f test.for -pc \:/ -ef C:\BIN\f1.err -Q 24242 -A
 lfd -4I 4 -Gs -Iinclude/ -I ./ -W 1  '
 compiling ccalls.fil
 compiling plan.cfd
 compiling direct.cfd
 compiling client.cfd
 compiling colors.cfd
 compiling empmas.cfd
 compiling emplfd.cfd
 compiling empldd.cfd
 compiling juffsa.cfd
 test.for(16) : fatal error F1909: : %s : include file nested too deeply
  : include file nested too deeply

 Response:
    The error message itself is not being produced correctly. You can
 work around this problem by placing the INCLUDE files in the same
 directory as the source file.
    Microsoft has confirmed this to be a problem in Version 4.00. We
 are researching this problem and will post new information as it
 becomes available.


 36. Linking With 3.20/3.30 Modules

 Product Version(s): 4.00A
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified:  5-MAY-1988    ArticleIdent: Q22172

 Question:
    When linking with the 3.20/3.30 compatible library (large model, 87
 support), I receive a message from LINK that it needs the LLIBFORE
 library. I am not specifying any FP switches at link time.
    What causes this? Could this happen if my 3.20/3.30 modules were
 compiled with $NOFLOATCALLS?

 Response:
    This should only occur if you are set up to link to LLIBFOR7.LIB.
    About twelve of the modules in Version 4.00 of FORTRAN.LIB have
 library search directives for LLIBFORE.LIB embedded in them. The
 linker will ask for LLIBFORE when the 3.20/3.30 routines call a
 library routine that has not already been loaded to satisfy a request
 from the main (Version 4.00) program.
    To workaround this, use the FL directive-link to alter the library
 search order.
    The following FL will compile and link without asking for
 LLIBFORE.LIB:

    FL V40.FOR -link MYLIB FORTRAN

    Since the Version 4.00 library contains the appropriate Version 3.x
 math library, it does not matter if $FLOATCALLS is used in the Version
 3.x routines.


 37. Text Beyond 72 Columns

 Product Version(s): 4.00A
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified:  5-MAY-1988    ArticleIdent: Q22178

 Problem:
    If text goes beyond 72 columns, FORTRAN Version 4.00 does not issue
 any kind of diagnostics. It generates code (which is incorrect code,
 because some of it is not submitted to the language translator). All
 of the other compilers on the market issue diagnostics.

 Response:
    You are partially correct. Unless truncation of the line to 72
 characters causes a syntax error, Version 4.00 does not issue any
 error message. This is program design for the product.
    Because the FORTRAN standard mandates that only the first 72
 columns be used for source code, a substantial body of mainframe
 FORTRAN code has been generated that relies on that fact and uses the
 remaining columns (generally 73-80) for other purposes (most commonly
 for sequencing information).
    If the presence of characters beyond column 72 was flagged as a
 warning, and you were porting programs with sequencing information in
 columns 73-80, you would receive such a warning for every line. The
 listing file format provided by Version 4.00 of the Microsoft FORTRAN
 Optimizing Compiler will list the content of the first 72 characters
 of the source line and indicate the presence of additional characters
 beyond column 72 by adding a "#" just before the line number, e.g.
 line 10 in the following fragment of a .LST file:

   Line    Source    Microsoft FORTRAN Optimizing Compiler Version
   Number  Line      4.00

       1   c
       2   c
       3   c
       4   c
       5   c
       6
       7          program test
       8          open(3,file='xxxx.dat',status='old')
       9          rewind 3
      10          read(3,10)i1,i2,i3,i11,i12,i21,i22,i23,i24,
                  i25,i26,i27,i28,i29
      11  10      format(5i3,13i1)
      12          write(*,*)i1,' ',i2,' ',i3
      13          write(*,*)i11,' ',i12
      14          write(*,*)i21,i22,i23,i24,i25,i26,i27,i28,i29,
                  i30,i31,i32,i33
      15          end

    Please note that the variable i31 became variable i3, which causes
 incorrect output from this program.
    Neither of the two other microcomputer FORTRAN compilers that we
 tried directly diagnosed the presence of characters beyond column 72.


 38. FORTRAN and C Compatability in Protect Mode

 Product Version(s): 4.10
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 17-MAR-1988    ArticleIdent: Q27843

 Question:
    How do I link my FORTRAN and C modules when I have built my FORTRAN
 libraries with C compatibility? I link as follows:

 LINK objs,,,LLIBCEP.LIB LLIBFEP.LIB DOSCALLS.LIB /NOE /NOD;

 Response:
    It is not necessary to use F4COMPAT.BAT for protect mode programs.
 Any of the three math packages can be used as long as they are
 consistent between the languages. The C library must be the first
 library, the FORTRAN library and DOSCALLS.LIB must be linked
 explicitly, and the switches /NOE and /NOD must be used. The /NOE
 switch is used to prevent symbols from being defined more than once
 (error L2025). The /NOD switch turns off the default library search so
 that the order of these libraries can be given explicitly. For
 information on linking real mode programs, please refer to the C 5.00
 README.DOC section entitled "Linking Mixed-Language Programs."


 39. Device Full Error

 Product Version(s): 4.00
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist4.00 fixlist4.01
 Last Modified: 27-MAY-1988    ArticleIdent: Q22177

 Problem:
    There seems to be a problem using OPEN or CLOSE on a logical unit
 where you have had an error 6422 ("no space left on device") that is
 caught in a WRITE statement. Any attempt to CLOSE or OPEN the same
 logical unit will give the same error. The example that I have opens a
 file on an almost full disk, writes until it produces the above error,
 and then attempts to CLOSE the file.

 Response:
    This is a known problem in Version 4.00. It was corrected in
 Version 4.01.
    The program tries to recover from the "no space" condition by using
 the STATUS='DELETE' specifier to delete the file.
    The error is not being cleared because when a CLOSE is done, the
 file's last buffer is being flushed before a check is done to see
 whether you specified that the file be deleted. There is no
 workaround.


 40. Error in Rounding Code

 Product Version(s): 4.00
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist4.00 fixlist4.01
 Last Modified: 27-MAY-1988    ArticleIdent: Q22143

 Question:
    I have encountered an error in the rounding code. Is there a
 solution available? The following is sample code:

     real*4 n1
     character*20 str

     n1=0.01
     write(str,12) n1
     write(*,*) str
 12  format(f9.2)

    F9.2 format rounds the number to 0.00.

 Response:
    Microsoft confirmed this to be a problem in Version 4.00 of the
 FORTRAN Compiler. The problem was corrected in Version 4.01.
    The problem does not occur for all values of n1 (try .02), but will
 occur whether the WRITE is to an internal or external file.


 41. Internal Compiler Error: getattrib.c 1.40, Line 162

 Product Version(s): 4.00a
 Operating System:   MS-DOS
 Flags: ENDUSER | ptr900051 bcp1542 buglist4.00
 Last Modified:  1-JUN-1988    ArticleIdent: Q22227

 Problem:
    The following program will produce the assertion error
 getattrib.c:1.40, line 162:

    implicit real (A - Z)
    integer*2    I CHAR
    integer*2    I SCAN
    integer*2    OPTION
    character*01 DRIVE
    common /valset/ allcharacters,  alphabetic, alphanumeric,
    &                numeric,    protected,  signed
    character*1  PROD ARRAY (36)
    character*36 PROD
    character*13 PRD KEY
    character*2  PRD DIV
    character*1  PRD FIL
    integer*4    PRD RET
    equivalence (PROD ARRAY  (1), PROD, PRD KEY, PRD DIV),
    &            (PROD ARRAY (33),                PRD RET)
    common /PROD CM/ PROD
    end
    subroutine UPDATE
    implicit real (A - Z)
    character*14 SET DD
    character*1  PROD ARRAY (36)
    character*36 PROD
    character*13 PRD KEY
    character*2  PRD DIV
    character*1  PRD FIL
    integer*4    PRD RET
    equivalence (PROD ARRAY  (1), PROD, PRD KEY, PRD DIV),
    &            (PROD ARRAY (33),                PRD RET)
    common /PROD CM/ PROD
    PRD KEY = '.............'
    PRD FILLER = ' '
    end

 Response:
    This is a known problem in Version 4.00.
    Microsoft is researching this problem and will post new information
 as it becomes available.
    It seems that this problem has to do with EQUIVALENCE between
 CHARACTER and non-CHARACTER data.
    Note that the assertion error only happens on an 80286; on an
 80386, you will receive an "error 2100 : Floating point error : stack
 underflow", after which the machine will hang. This happens even on a
 patched DOS Version 3.2.


 42. Internal Compiler Error: regMD.c 1.74, Line 2156

 Product Version(s): 4.00a
 Operating System:   MS-DOS
 Flags: ENDUSER | ptr900054 bcp1545 buglist4.00 fixlist4.01
 Last Modified:  1-JUN-1988    ArticleIdent: Q22232

 Problem:
    The following program causes a regMD.c:1.74, line 2156 assertion
 error:

         u = 1. /
      +      (xa+ 1. /
      +      (xa+ 2. /
      +      (xa+ 3. /
      +      (xa+ 4. /
      +      (xa+ 5. /
      +      (xa+ 6. /
      +      (xa+ 7. /
      +      (xa+ 8. /
      +      (xa+ 9. /
      +      (xa+ 10. /
      +      (xa+ 11. /
      +      (xa+ 12. / xa ))))))))))))
         end

 Response:
    This is a known problem in Version 4.00a of the FORTRAN compiler.
 It was corrected in Version 4.01.
    The only workaround is to break the statement into smaller
 segments.


 43. Null Pointer Assignment at Compile Time

 Product Version(s): 4.00a
 Operating System:   MS-DOS
 Flags: ENDUSER | ptr900048 bcp1532 ptr900049 bcp1534 buglist4.00a fixlist4.01
 Last Modified:  1-JUN-1988    ArticleIdent: Q22235

    The following code gives a "null pointer assignment" error if
 compiled with -4Yb ($DEBUG):

    character cfunc,arg
    arg = 'X'
    write (*,*) cfunc (arg)
    end
    character function cfunc (arg)
    character arg
    cfunc = arg
    end

    Note that the following program also produces a "null pointer
 assignment" message during compilation if -4Yb is used:

    SUBROUTINE MAPINPUT (FILENAME)
    CHARACTER*(*) FILENAME
    OPEN (1,FILE=FILENAME)
    END

    Microsoft has confirmed this to be a problem in Version 4.00a of
 the FORTRAN Compiler. This problem was corrected in Version 4.01.

    In the first example, this occurs because a CHARACTER function is
 used in a WRITE statement (but only when compiled with -4Yb).
    The second example produces the same error, probably for the same
 internal reason, but there is no CHARACTER function this time.
 Instead, there is a CHARACTER*(*) parameter associated with an I/O
 statement.


 44. Concatenation Operator

 Product Version(s): 4.00a
 Operating System:   MS-DOS
 Flags: ENDUSER | ptr900055 bcp1548 buglist4.00 fixlist4.01
 Last Modified:  1-JUN-1988    ArticleIdent: Q22236

    The following program should output PQRS2345, but it only outputs
 PQRS:

         J=3
         CALL SUBA(J)
         END

         SUBROUTINE SUBA(J)
         CHARACTER*8 A
         CHARACTER*4 H
         COMMON /AAA/H(3)
         h(1)='ABCD'
         H(2)='PQRS'
         H(3)='2345'

    Microsoft has confirmed this to be a problem in Version 4.00 of the
 FORTRAN Compiler. It was corrected in Version 4.01.
    The following statement can be inserted as a workaround:

         H(J) = H(J)
         A=H(2)//H(J)
         WRITE(0,999)A
 999     FORMAT(' A=',A8)
         END

    This problem seems only to affect the second operand of a
 concatenation if the second operand is a COMMON variable.


 45. Internal Compiler Errors: ctypes.c, MDmisc.c, expand.c

 Product Version(s): 4.00
 Operating System:   MS-DOS
 Flags: ENDUSER | ptr900056 bcp1549 buglist4.00
 Last Modified:  2-JUN-1988    ArticleIdent: Q22237

    The following subroutine will produce four different internal
 compiler errors, depending on how "k" is typed:

    subroutine inerr(endprnt)
    integer endprnt

    The following errors are produced:

    1. "Character*4" will produce an error in ctypes.c line 355 if
 compiled with -4I2, as follows:

    character*4 k

    2. "Character*10" will produce an error in ctypes.c line 426 if
 compiled with -4I2, as follows:

    character*10 k

    3. "Character*1" will produce an error in MDmisc.c line 844, as
 follows:

    character*1 k

    4. "Character*2" will produce an error in expand.c line 1350, in
 the following program:

              character*2 k
              lr=1
              write(endprnt,40)k(lr),k(lr+1),k(lr+2),k(lr+3)
    40        format(1x,4A10)
              end

    This is a known problem in Version 4.00.
    Microsoft is researching this problem and will post new information
 as it becomes available.
    The problem apparently involves the recognition of a CHARACTER
 function as an argument to a WRITE or an OPEN statement.


 46. EOF When Value Equals 26 in a Binary file

 Product Version(s): 4.00
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist4.00 fixlist4.01
 Last Modified:  1-JUN-1988    ArticleIdent: Q22238

    The program below (deof.for) will get an end-of-file (EOF) if the
 value read in is equal to 26. This happens only if the variable is
 integer*1 (integer*2 produces the proper results). It is my
 understanding that the 26 should not be treated as EOF if it is a
 binary file.
    The program is as follows:

    integer*1 i1,i2
    open(1,file='def.dat',form='binary')
    i1=22
    i2=26

    write(1) i1
    write(1) i2

    rewind (1)

    read(1) i1
    write(*,*) i1

    read(1) i2
    write(*,*) i2

    end

    Microsoft has confirmed this to be a problem in Version 4.00 of the
 FORTRAN Compiler. It was corrected in Version 4.01.

    In FORM='BINARY', you should be able to READ anything that you
 WRITE to a file (if you rewind the file), including CONTROL-Z. The
 problem is not restricted to INTEGER*1. What determines the failure is
 that the very last byte written to a file is a CONTROL-Z. When
 READing, if the run time sees a CONTROL-Z in its buffer, it strips it
 out. In this program, this causes a premature end-of-file.
    This program will fail in the same way if you change variable I2 to
 be INTEGER*2 and give it a value of #1A1A. (Due to byte swapping,
 INTEGER*2 storage of the value 26 is #1A00. Thus, because the last
 byte was zero, you did not see it fail.)


 47. Internal Compiler Error: exhelp.c 1.55, Line 662

 Product Version(s): 4.00
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified:  1-JUN-1988    ArticleIdent: Q22240

 Problem:
    FORTRAN Version 4.00 generates the following internal compiler
 error:

    exphelp.c:1.55, line 662

 Response:
    Line 8, "B(I) = REAL(I) - CMPLX(I)", generates the above internal
 compiler error. B is COMPLEX*16 and I is INTEGER*2. The error goes
 away if you change the statement to the following:

    T = CMPLX(I)
    A(I) = REAL(I) - T

    The first file (bernard.for) generates the internal error. The
 second file (bernard2.for) adds the variable T to fix the problem.
 The following is the first file:

    program test
    integer*2 maxamt
    parameter (maxamt=5)
    complex*16 b(maxamt)
    integer*2 i

    do 1,i=1,maxamt
      b(i) = real(i) - cmplx(i)
 1    continue
    end

    REAL(I) converts I to REAL*4. CMPLX(I) converts I to COMPLEX*8.
    The problem can also be worked around by compiling with the -Odclt
 option.


 48. END= and Implied-DO READS

 Product Version(s): 4.00a 4.01
 Operating System:   MS-DOS
 Flags: ENDUSER | ptr900058 bcp1554 buglist4.00a buglist4.01
 Last Modified:  1-JUN-1988    ArticleIdent: Q22244

    The following program should produce two identical lines:

         dimension x(15)
         open (1,form='formatted')
         write (1,'(i5)') (i,i=1,10)
         rewind 1
         i = 0
 5       continue
         i = i+1
         read (1,*,end=10) x(i)
         go to 5
 10      continue
         i = i-1
         write (*,*) 'From first read, i=',i,':'
         write (*,'(1x,15f3.0)') (x(j),j=1,i)
         rewind 1
         read (1,*,end=20) (x(i),i=1,15)
 20      continue
         i = i-1
         write (*,*) 'From second read, i=',i,':'
         write (*,'(1x,15f3.0)') (x(j),j=1,i)
         end

    The output should be as follows:

    >From first read, i=         10:
     1. 2. 3. 4. 5. 6. 7. 8. 9.10.
    >From second read, i=         10:
     1. 2. 3. 4. 5. 6. 7. 8. 9.10.

    However, it looks like the following:

    >From first read, i=         10:
     1. 2. 3. 4. 5. 6. 7. 8. 9.10.
    >From second read, i=         15:
     1. 2. 3. 4. 5. 6. 7. 8. 9.10. 0. 0. 0. 0. 0.

    Microsoft is researching this problem and will post new information
 as it becomes available.

    This is a known problem in Versions 4.00a and 4.01.
    This problem will occur on READ statements that use implied-DO loops to
 read part or all of an array and that use the END= specifier to branch
 when end-of-file is reached.
    An inspection of the code reveals that no code is being generated
 to check for end-of-file when an implied-DO is used.


 49. Incorrect F2215 Errors

 Product Version(s): 4.00a
 Operating System:   MS-DOS
 Flags: ENDUSER | PTR900060 bcp1569
 Last Modified: 25-OCT-1988    ArticleIdent: Q22255

 The following program will generate an incorrect F2215 error
 ("character lengths differ"):

       SUBROUTINE PAGE
       IMPLICIT CHARACTER*1(A-H,J-Z)
       ENTRY PAGOUT
       END

 The compiler is issuing an error that is only appropriate for a
 function because subroutines have no type associated with them. The
 workaround for this problem is to avoid using the IMPLICIT CHARACTER
 statement; use explicit type statements instead.


 50. Macro Definitions Error

 Product Version(s): 4.00
 Operating System:   MS-DOS
 Flags: ENDUSER | docerr
 Last Modified: 25-OCT-1988    ArticleIdent: Q22284

 Question:

 Is there a documentation error on Page 174 in the "Microsoft
 FORTRAN Optimizing Compiler User's Guide" for Version 4.00 regarding
 macro definitions?

 Response:

 Yes, the following statement should be changed to indicate that double
 quotation marks around a macro are required only if the macro
 definition contains white space and is on the MAKE command line:

    "To include white space in a macro definition, enclose the entire
    definition in double quotation marks (" ")"

 Macro definitions inside a MAKE file should not be enclosed in
 quotation marks. Therefore, the following example on Page 175 is
 incorrect:

    warn="/W0"

 It should be changed to something such as the following:

    make warn= "-c -W2" compile


 51. -Gr Switch Operating Incorrectly

 Product Version(s): 4.00a
 Operating System:   MS-DOS
 Flags: ENDUSER | ptr900063 bcp1585 buglist4.00 fixlist4.01
 Last Modified:  1-JUN-1988    ArticleIdent: Q22292

    The -Gr switch is intended to be used when Version 3.20 object
 files or libraries are mixed with Version 4.00 main programs. Version
 3.20 object files may use the SI and DI registers without regard to
 their previous contents, and since Version 4.00 needs to use SI and
 DI, this switch was added to preserve their contents by pushing them
 onto the stack prior to subroutine or function calls and restoring
 them upon return.
    A problem is caused by the SI and DI registers being pushed after
 any arguments are pushed, rather than before. The -Gr switch will work
 if calls to subroutines or functions are made with no arguments, but
 programs containing subroutines or functions that have one or more
 arguments will either produce incorrect answers or behave
 unpredictably.
    Microsoft has confirmed this problem in Version 4.00 of the FORTRAN
 Compiler. This problem was corrected in Version 4.01.

    Here is an example of a program that recreates the problem. The
 following program:

         character*5 c,cfunc
         i = 1
         x = 2.0
         c = '34567'
         call junk (i,x,c)
         c = cfunc ('abcde')
         write (*,*) 'Function return value should be ''abcde'', is=',c
         end
         subroutine junk (j,y,cx)
         character cx*5
         write (*,*) 'First parameter should be 1, is=',j
         write (*,*) 'Second parameter should be 2.0, is=',y
         write (*,*) 'Third parameter should be ''34567'', is=',cx
         end
         character*(*) function cfunc(c)
         character*(*) c
         cfunc = c
         end

 should produce the following output:

    First parameter should be 1, is=          1
    Second parameter should be 2.0, is=       2.000000
    Third parameter should be '34567', is=34567
    Function return value should be 'abcde', is=abcde

 However, when compiled with -Gr, the output is as follows:

    First parameter should be 1, is= 1073741824
    Second parameter should be 2.0, is=   2.700149E-06
    Third parameter should be '34567', is=\016X>$
    run-time error F6602: WRITE(CON)
    - list-directed number bigger than record size


 52. Internal Compiler Error: omf.c 1.59, Line 185

 Product Version(s): 4.00a
 Operating System:   MS-DOS
 Flags: ENDUSER | ptr900053 bcp1544 buglist4.00 fixlist4.01
 Last Modified:  1-JUN-1988    ArticleIdent: Q22233

 Problem:
    The following program causes an omf.c:1.59, line 185 assertion
 error if compiled with the -Fc option:

         dimension jn(8192)
         write (*,'(4i15)') jn
         end

 Response:
    This is a known problem in Version 4.00a of the FORTRAN compiler.
 It was corrected in Version 4.01.
    The pattern here is that it must be a formatted write, and the
 argument to the WRITE must be part or all of an array that is more
 than 32K in length.


 53. Code Generation Errors when Compiling with -4Yb and -Od

 Product Version(s): 4.00A
 Operating System:   MS-DOS
 Flags: ENDUSER | ptr900050 bcp1535 buglist4.00 fixlist4.01
 Last Modified: 27-MAY-1988    ArticleIdent: Q22225

    The following program causes multiple code generation errors if
 compiled with -4Yb and -Od:

    SUBROUTINE OPED1
    CHARACTER*70 COMMENT(2)
    IF (COMMENT(1)(I:I) .EQ. ' ') i = 1
    IF (ICHAR(COMMENT(1)(I:I)) .NE. 0) i =1
    END

 Problem:
    Microsoft has confirmed this to be a problem in Version 4.00 of the
 FORTRAN Compiler. It was corrected in Version 4.01.
    This is probably related to an earlier problem that caused an
 assertion error in ctypes.c:1.80, line 1594. In fact, this program
 will cause the same assertion error if the -Od option is not used.
 Note that the error will not occur unless both of the IF statements
 are present.


 54. Compile Error F2328

 Product Version(s): 4.00A 4.01
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist4.00a buglist4.01
 Last Modified: 27-MAY-1988    ArticleIdent: Q22208

 Problem:
    The following subroutine produces compilation error F2328 ("N :
 already typed"):

       subroutine x (a,n)
       real a(n)
       integer n
       a(1) = 1.0
       end

 Response:
    This is a known problem in Versions 4.00a and 4.01 of the FORTRAN
 Compiler.
    The program is valid, but the compiler reacts as if the presence of
 N in the REAL declaration statement "declares" N to be type INTEGER.
 Because N has been "declared" INTEGER, the compiler reports an error
 when the next statement attempts to declare it.
    To work around this compiler error, declare all variables used as
 bounds for adjustable-size arrays before declaring the arrays
 themselves.
    Microsoft is researching this problem and will post new information
 as it becomes available.


 55. Run-Time Error F6099 Integer Overflow -4Yb -4I2

 Product Version(s): 4.00 4.01
 Operating System:   MS-DOS
 Flags: ENDUSER | ptr900064 bcp1587 buglist4.00 buglist4.01
 Last Modified:  1-JUN-1988    ArticleIdent: Q22291

 Problem:
    The following program produces run-time error F6099 (INTEGER
 overflow) if it is compiled with -4I2 and -4Yb:

         dimension j(200,160)
         do 10 i=1,200
         write (*,*) 'i=',i
         do 10 k=1,160
         write (*,*) 'k=',k
 10      j(i,k)=0
         end

    It writes out i=1 and j=1,2,3...82 and then terminates.

 Response:
    This is a known problem in Versions 4.00 and 4.01 of the FORTRAN
 compiler.
    The array subscript calculation is being done in INTEGER*2
 arithmetic, so when you get to j=82, it is attempting to multiply 400
 (200 elements, 2 bytes each) by 82, which is 32800. However, since
 $4Yb is in effect, the program gives the error and stops. This also
 will happen if you explicitly make the array INTEGER*2 and compile
 with just -4Yb.
    The workaround is to reduce the size or length of the character
 array to the point where size (200 elements in this case) times the
 length (2) is less than 32768 bytes.
    Microsoft is researching this problem and will post new information
 as it becomes available.


 56. Unformatted WRITE Hangs

 Product Version(s): 4.00A
 Operating System:   MS-DOS
 Flags: ENDUSER | ptr900062 bcp1580 buglist4.00 fixlist4.01
 Last Modified: 27-MAY-1988    ArticleIdent: Q22287

 Problem:
    The following program hangs at run time:

         dimension i(5)
         data i /1,2,3,4,5/
         data n /0/
         open (1,form='unformatted')
         write (1) (i(j),j=1,n)
 cx      write (1) (i(j)*1,j=1,n)
         close (1,status='delete')
         end

 Response:
    Microsoft has confirmed this to be a problem in Version 4.00 of the
 FORTRAN Compiler. It was corrected in Version 4.01.
    The program hangs because it is trying to write zero elements of
 the array. It is peculiar to unformatted I/O and happens only if the
 number of elements to be transferred is zero.
    If you want to be able to write zero elements, a workaround is to
 put the array element into an expression. Replacing the existing WRITE
 with the commented-out WRITE allows the above program to run.


 57. Purpose of the /Gr Switch

 Product Version(s): 4.00A
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified:  1-DEC-1987    ArticleIdent: Q22267

 Question:
    We are a little unclear on exactly what the /Gr switch does. Is it just
 that the object file format is different, or are the object references
 different?

 Response:
    The only effect the /Gr switch has is that, prior to any
 subroutine/function call, the SI and DI registers are pushed onto the stack,
 and upon return they are popped. Since Version 3.x routines may use SI and DI
 for their own purposes, the /Gr switch was added to preserve their Version 4.
 values across calls.


 58. NDP Stack Underflow

 Product Version(s): 4.00A
 Operating System:   MS-DOS
 Flags: ENDUSER | ptr900061 bcp1571 buglist4.00 fixlist4.01
 Last Modified: 27-MAY-1988    ArticleIdent: Q22264

 Problem:
    I am receiving the following error message:

    run-time error M610: MATH
    - floating-point error: stack underflow

    I receive the above error message when I run the following program:

         data x /0.0/
         y = 0.0
         if (x .ne. 0.0) y = 1.0
         z = 1.0
         write (*,*) y,z
         end

 Response:
    Microsoft has confirmed this to be a problem in Version 4.00 of the
 FORTRAN Compiler. It was corrected in Version 4.01.
    The optimizer assumes that the constant 1.0 is on the NDP stack, so
 when it tries to assign 1.0 to Z, it simply does an FSTP
 (floating-store-pop) instruction. Unfortunately, since 1.0 will be put
 on the stack only if X is not equal to 0.0, the program fails.
    The workaround is to compile with -Od.


 59. Code Generation Error, WRITE Statement

 Product Version(s): 4.00A
 Operating System:   MS-DOS
 Flags: ENDUSER | ptr900059 bcp1568 buglist4.00 fixlist4.01
 Last Modified: 27-MAY-1988    ArticleIdent: Q22259

 Problem:
    The following program produces a code generation error:

       real bs(3,3),br(3,3),ps(3,3),psp(3),bsp(3),bso(3),rp(3),ro(3)
           WRITE(6,350)
      +  aguse(I,J)/customers(J),
      x  agg(bs(I,J),1.0)+AGG(BR(I,J),1.0),
      +  AGG(BR(I,J)-PS(I,J),1.0),
      X  AGG(BS(I,J)+BR(I,J)-PS(I,J),1.0)
   350 FORMAT(3(1X,A22,F9.1,7F8.2,3X,F8.2))
         end

 Response:
    Microsoft has confirmed this to be a problem in Version 4.00 of the
 FORTRAN compiler. It was corrected in Version 4.01.
    The problem here apparently involves the expressions used as
 arguments to the WRITE statement. A possible workaround would be to
 store the expressions in temporary variables and WRITE those instead.


 60. Run-Time Error F6419 in Series of READs

 Product Version(s): 4.00
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist4.00 fixlist4.01
 Last Modified: 27-MAY-1988    ArticleIdent: Q22258

 Question:
    I receive run-time error F6419 in the middle of a series of READS.
 How can I prevent this?

 Response:
    This error means "illegal structure for unformatted file." You may
 be able to prevent the error by raising the BLOCKSIZE of the file.
    Microsoft has confirmed this to be a problem in Version 4.00 of the
 FORTRAN compiler. It was corrected in Version 4.01.


 61. Opening COM1/AUX

 Product Version(s): 4.00A
 Operating System:   MS-DOS
 Flags: ENDUSER | ptr90005 bcp1543 buglist4.00 fixlist4.01
 Last Modified:  1-JUN-1988    ArticleIdent: Q22234

    The statement "open(3,file='com1')" generates the following error
 message:

    Error 6415: OPEN(COM1)
    -file already exists-

    The status in this OPEN statement is unknown, but the documentation
 on the error message indicates that the OPEN statement specified
 status='new'. If you explicitly specify status='old' in the open
 statement, then the error is not generated.
    Microsoft has confirmed this to be a problem with Version 4.00A of
 the FORTRAN Compiler. This problem was corrected in Version 4.01.
    Another workaround for this (besides the one mentioned above) is to
 open file 'LINE', which will access the same place. The difference is
 that when the run time sees the name 'LINE' it does not check the
 "STATUS" of the file, but it does check the "STATUS" for COM1.


 62. Unresolved External: __FHcfsubrd

 Product Version(s): 4.00A
 Operating System:   MS-DOS
 Flags: ENDUSER | ptr900057 bcp1553 buglist4.00 fixlist4.01
 Last Modified:  1-JUN-1988    ArticleIdent: Q22239

    The following program produces an resolved external at link time if
 compiled with -FPc:

    complex z6,ans
    ans = 1.0-z6
    end

    Microsoft has confirmed this to be a problem in Version 4.00A of
 the FORTRAN Compiler. This problem was corrected in Version 4.01.
    There is no simple workaround for this problem except to compile
 with -FPi.


 63. GETFONTINFO: Documentation Error in Type Definition

 Product Version(s): 5.00
 Operating System:   MS-DOS
 Flags: ENDUSER | docerr
 Last Modified: 23-APR-1990    ArticleIdent: Q60842

 The interface statement for the GETFONTINFO function shown on Page 209
 of the "Microsoft FORTRAN Advanced Topics" manual incorrectly lists
 the following line:

    INTEGER*2 avegwidth          !Average width in pixels

 The line should read as follows to conform to the definition in the
 include file FGRAPH.FD:

    INTEGER*2 avgwidth           !Average width in pixels


 64. Writing More Than 132 Characters to a Device

 Product Version(s): 4.00a
 Operating System:   MS-DOS
 Flags: ENDUSER | ptr900006 bcp1361 buglist4.00 fixlist4.01
 Last Modified:  1-JUN-1988    ArticleIdent: Q22283

    Attempting to WRITE more than 132 characters to a device (CON, PRN,
 etc.) will cause random characters to be written. The following
 program demonstrates the problem:

    i = 12345
    write (*,'(i150)') i
    end

    This involves a problem with the run-time code that handles buffer
 overflows. The problem only occurs with WRITEs to devices, not files.
 Note, however, that files created by redirecting CON output also will
 be affected.
    A patch has been developed that will work around the problem by
 allowing the size of the device buffers to be increased. The patch
 raises the buffer size from 132 to 256 bytes. If you wish to write
 longer records, you can raise the limit to as high as 32255 bytes.
    To patch the FORTRAN Version 4.00 libraries to correctly handle
 records longer than 132 bytes written to devices, perform the
 following patch, which increases the buffer size from 132 (0084 hex)
 to 256 (0100 hex):

    /* patch the large model library first */
    LIB LLIBFOR *CORE;
    DEBUG CORE.OBJ
    E ES:48E
    00 01   /* replace the bytes 84 and 00 with bytes 00 and 01 */
    E ES:4C6
    00 01                  /* must be same two bytes */
    E ES:1052
    00 01                 /* must be same two bytes again */
    W
    Q
    LIB LLIBFOR -+CORE;

    /* now for the medium model library */
    LIB MLIBFOR *CORE;
    DEBUG CORE.OBJ
    E ES:48A
    00 01    /* replace the bytes 84 and 00 with bytes 00 and 01 */
    E ES:4C2
    00 01                    /* must be same two bytes */
    E ES:E21
    00 01                    /* must be same two bytes again */
    W
    Q
    LIB MLIBFOR -+CORE;

    /* done */

    Please note that you can increase the buffer size up to 32255 (7DFFH,
 entered as FF 7D). Never enter more than two bytes at any of the above
 locations.
    If the first byte to be changed at each address is not 84
 (hexadecimal), stop and confirm that you entered the correct address.
   Microsoft has confirmed this to be a problem in Version 4.00 of the
 FORTRAN compiler. This problem was corrected in Version 4.01.


 65. CTRL+Z Versus INCLUDE Files

 Product Version(s): 4.00a
 Operating System:   MS-DOS
 Flags: ENDUSER | ptr900067 bcp1603 buglist4.00 fixlist4.01
 Last Modified: 30-SEP-1988    ArticleIdent: Q22307

 Problem:

 My main program is as follows:

    c
    c This is the main program
    c
    c Now the include file (which has a CTRL+Z as the last character)
    $INCLUDE:'bcp1603a.for'
    c Since the CTRL+Z has been echoed from the INCLUDE file
    c You will not see these comments if you TYPE the .LST file
            end

 My INCLUDE file (which has a CTRL+Z as the last character) is as
 follows:

    c this is the first line of the include file
    c
    c
    $nofloatcalls
    c this is the last line of the include file

 Any attempt to TYPE the resulting .LST file stops at the end of the
 INCLUDE file.

 Response:

 Microsoft has confirmed this to be a problem in Version 4.00 of the
 FORTRAN compiler. This problem was corrected in Version 4.01.

 The CTRL+Z character in the INCLUDEd file is being sent to the .LST
 file and should not be. A workaround to this problem is to use the DOS
 COPY command (i.e., if file XX ends with a CTRL+Z, the following COPY
 command will create file YY, which has all the same information
 without the CTRL+Z character at the end):

 COPY XX/A YY


 66. More Than One Unnamed BLOCK DATA

 Product Version(s): 4.00
 Operating System:   MS-DOS
 Flags: ENDUSER | ptr900069 bcp1614 buglist4.00 fixlist4.01
 Last Modified:  1-JUN-1988    ArticleIdent: Q22351

    The compiler should give an error for the following program, but it
 does not:

    block data
    end
    block data
    end

    The ANSI X3.9-1978 FORTRAN standard states, "There must not be more
 than one unnamed BLOCK DATA subprogram in an executable program."
    Microsoft has confirmed this to be a problem in Version 4.00 of the
 FORTRAN Compiler. This problem was corrected in Version 4.01.
    This error may result in incorrect data being placed into the
 labeled COMMON blocks. If you have more than one BLOCK DATA
 subprogram, the obvious (and correct) solution is to use named BLOCK
 DATA subprograms: one may be unnamed, but the rest must be named.


 67. Problem Reading LIB.CMP

 Product Version(s): 4.00A
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist4.00 fixlist4.01
 Last Modified: 27-MAY-1988    ArticleIdent: Q22339

    The following program hangs the system:

    character*5 c
    open(4,file='LIB.CMP')
    read(4,'(a)')c
    end

    This problem occurs because although LIB is not a device name,
 "LINE" is. This is another example of the PRN versus PRM problem. The
 hang occurs because "LINE" is mapped to COM1, so the program hangs
 while waiting for input.
    Microsoft has confirmed this to be a problem in Version 4.00 of the
 FORTRAN Compiler. It was corrected in Version 4.01.


 68. FL -Od *.for Error

 Product Version(s): 4.00a
 Operating System:   MS-DOS
 Flags: ENDUSER | ptr900065 bcp1601 buglist4.00 fixlist4.01
 Last Modified: 25-OCT-1988    ArticleIdent: Q22338

 Problem:

 When several separate source files and one of the following FL
 commands are used, different errors are received than if the routines
 are compiled one at a time:

    FL -Od *.for
    FL -Od a.for b.for c.for

 Response:

 Microsoft has confirmed this to be a problem in Version 4.00 of the
 FORTRAN compiler. This problem was corrected in Version 4.01.

 FL is compiling the first of the files correctly, but all subsequent
 files are being compiled as if they were compiled with the default
 maximum optimization. If -Od is going to be used, one workaround to
 this problem is to compile each source file separately.


 69. Internal Compiler Error: p3io.c, Line 604

 Product Version(s): 4.00a
 Operating System:   MS-DOS
 Flags: ENDUSER | ptr900070 bcp1616 buglist4.00 fixlist4.01
 Last Modified:  1-JUN-1988    ArticleIdent: Q22332

 Problem:
    The following program produces a p3io.c, line 604 assertion error:

         SUBROUTINE PLSAVE
         COMMON /PLSAVE/ YOO
         YOO = YO
         END

    If compiled with -Od, it produces the following assertions:

    omf_ms.c, line 985
    %Z%%M%:%I%, line 604
    code.c, line 167

 Response:
    This is a known problem in Version 4.00 of the FORTRAN compiler. It
 was corrected in Version 4.01.
    Error F2325 is generated under Version 4.01, as it should be.
    The pattern here seems to be that the SUBROUTINE and COMMON blocks
 have the same name. A workaround is to rename either the SUBROUTINE or
 COMMON block.


 70. "STOP 1" Message

 Product Version(s): 4.00A
 Operating System:   MS-DOS
 Flags: ENDUSER | ptr900068 bcp1612 buglist4.00 fixlist4.01
 Last Modified: 27-MAY-1988    ArticleIdent: Q22308

    The following program:

    stop 1
    end

 should print as follows:

    Return code 1

    Instead, it prints the following:

    Return code Pause - 1

    Microsoft has confirmed this to be a problem in Version 4.00 of the
 FORTRAN Compiler. It was corrected in Version 4.01.


 71. Compile Time Error F2570

 Product Version(s): 4.00A
 Operating System:   MS-DOS
 Flags: ENDUSER | ptr900066 bcp1602 buglist4.00 fixlist4.01
 Last Modified: 27-MAY-1988    ArticleIdent: Q22306

    Compiling the following program:

    Plyevl(X1) = A1+X1*(A2+X1*(A3+X1*(A4+A5*X1)))
    B = PLYEVL(-C)
    END

 generates the following error:

    bcp1602.for(2) : error F2570: consecutive arithmetic operators illegal

    Microsoft has confirmed this to be a problem in Version 4.00 of the
 FORTRAN Compiler. It was corrected in Version 4.01.
    This problem can be worked around by setting a temporary variable
 equal to -C and using it as the argument to the statement function.


 72. Compiling C Program on Page 273 of the User's Guide

 Product Version(s): 4.00 4.01
 Operating System:   MS-DOS
 Flags: ENDUSER | docerr
 Last Modified:  7-SEP-1988    ArticleIdent: Q22329

 Problem:

 I get errors when I try to compile the C program on Page 273 of the
 "Microsoft FORTRAN Optimizing Compiler User's Guide" (Section 11.3.4).

 Response:

 To compile the program, you need to change the second line of the
 program by removing the semicolon (;). The first three lines should
 read as follows:

    long time(long *);
    long time(tloc)
    long *tloc;


 73. Invalid Object Module

 Product Version(s): 4.x
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified:  9-JUN-1988    ArticleIdent: Q22314

 Problem:
    I compile my module with no errors, but the linker generates the
 following error message when I link it:

    "Invalid object module"

    I have the ".FOR" extension on the end of my file on the FL command
 line. I also tried using the /Tf switch.

 Response:
    You probably are using the wrong version of the linker. You should
 be using the linker that comes with FORTRAN.
    To determine which linker you are using, do the following:

    1. Change to the directory from which you normally compile and link.
    2. Type "link".
    3. Change to the directory in which the FORTRAN compiler and linker
 reside.
    4. Type "link" again.

    The copyright message will display a version number. If these
 version numbers do not match, the linker that you are picking up is
 not the linker that came with your Microsoft FORTRAN.
    You are picking up another LINK.EXE on your system. LINK.EXE comes
 with DOS and other Microsoft language products.
    To confirm that you are picking up the wrong version, see if the
 correct LINK.EXE Version is not in your current directory. Also, see
 if your PATH environment variable is pointing to a directory that
 contains an older LINK.EXE before it points to the directory that the
 correct version is in.
    To work around this problem, do one of the following:

    1. Rename your old linkers to LINK.OLD.
    2. Change your path so that the PATH environment variable points
 to the directory that the correct version of LINK.EXE is in.

    If this does not correct the problem and you are using the correct
 LINK.EXE version, please send Microsoft Product Support Services a
 copy of your source file as a supplement to your technical assistance
 request.


 74. BTEST Function with Different Sized Arguments

 Product Version(s): 4.00a
 Operating System:   MS-DOS
 Flags: ENDUSER | ptr900071 bcp1618 buglist4.00 fixlist4.01
 Last Modified:  1-JUN-1988    ArticleIdent: Q22342

    The following subroutine will cause unpredictable behavior (hangs,
 possibly a reboot):

            integer*2 i2
            i2 = 10
            do 100 i4=0,7
            if (btest(i2,i4)) write (*,*) 'Bit set is=',i4
    100     continue
            end

    Microsoft has confirmed this to be a problem in Version 4.00 of the
 FORTRAN Compiler. This problem was corrected in Version 4.01.
    This should happen only under the following conditions:

    1. The first argument's size is INTEGER*2.
    2. The program is not compiled with -4I2.

    Apparently, the routine being called to do the test is assuming
 that the second argument is the same size as the first.
    A quick way to verify that BTEST will not fail at run time is to
 look at the code (via -Fc or -Fa). If only four bytes are pushed
 before the call, it will fail. If six bytes are pushed, it will run.
 Note that INTEGER*2 BTEST is done by in-line code.


 75. Run-Time Error F6419 Terminating on 78th Record

 Product Version(s): 4.00A
 Operating System:   MS-DOS
 Flags: ENDUSER | ptr900076 bcp1635 buglist4.00 fixlist4.01
 Last Modified: 27-MAY-1988    ArticleIdent: Q22380

 Problem:
    The following program will terminate on the 78th record with the
 error message "error F6419: illegal structure for unformatted file":

       DIMENSION KST(24),SPEED(24),TEMP(24),AFV(24),RFV(24),HLH(2,24),
      1 UU(24),UR(24)
       OPEN(8,FILE='bcp1635.dat',STATUS='OLD',FORM='UNFORMATTED')
       READ(8) ID,IY,IDM,IYM
       DO 100 N=1,366
       WRITE(*,150) N
  150  FORMAT('                         READING DAY ',I3)
       READ(8) IYEAR,IMONTH,DAY1,KST,SPEED,TEMP,AFV,
      1 RFV,HLH
  100  CONTINUE
       END

 Response:
    Microsoft has confirmed this to be a problem in Version 4.00 of the
 FORTRAN compiler. It was corrected in Version 4.01.
    To work around this problem, if you are creating unformatted files
 for use as a temporary storage medium, change the FORM= specifier from
 'UNFORMATTED' to 'BINARY'. The READ and WRITE statements will stay the
 same.
    If you have existing unformatted data files (and cannot change
 them), you may be able to work around the problem by increasing the
 BLOCKSIZE specifier beyond the minimum 1024 bytes.


 76. Z Format Problem

 Product Version(s): 4.00a
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist4.00 fixlist4.01
 Last Modified:  1-JUN-1988    ArticleIdent: Q22340

    The following program will write too many characters to the
 monitor:

            character*10 short
            character*80 long
            short = 'abcd'
            long = 'xyz'
            write (*,100) short
            write (*,100) long
    100     format (1x,z)
            end

    Microsoft has confirmed this to be a problem in Version 4.00 of the
 FORTRAN Compiler. This problem was corrected in Version 4.01.
    The program is operating as expected, but it is a victim of the
 already known error that random characters will result if more than
 132 characters are written to the screen.
    The Z format, when used without the width specification, puts out
 two hex characters for each byte of the object (i.e., it puts out
 eight hex characters for an INTEGER*4, 16 for a REAL*8, etc.). In this
 case, writing out a CHARACTER*80 variable with a Z format means that
 160 characters will be printed, which demonstrates the problem of
 writing more than 132 characters to the screen.


 77. Opening a Scratch File as Unformatted

 Product Version(s): 4.00a
 Operating System:   MS-DOS
 Flags: ENDUSER | docerr
 Last Modified: 15-DEC-1988    ArticleIdent: Q22344

 Problem:

 Using the OPEN statement to connect the preconnected units 0, 5, or 6
 to a temporary file with form = 'unformatted' generates the following
 run-time error message:

 F6202
 -terminal I/O not consistent with OPEN options

 The following line of code causes the problem:

 open(6, form='unformatted')

 If file= is omitted in an OPEN statement, the compiler creates a
 temporary file. Therefore, this statement should not generate an error
 message.

 Response:

 This is a documentation issue. Page 102 of the "Microsoft FORTRAN
 Compiler Language Reference" manual should state that if the FILE=
 specifier is omitted in an OPEN statement for a unit other than the
 preconnected units 0, 5, and 6, the compiler creates a temporary file.

 Because the OPEN statement does not specify a filename, OPEN must
 decide whether the unit is already connected to a file. If it is not
 connected, unit 6 is opened as a scratch file. If the unit is
 connected to a file, then the BLANK specifier is the only allowed
 specifier.

 If you had specified open(3, form='unformatted'), a scratch file would
 have been created; however, units 0, 5, and 6 are preconnected
 FORM='FORMATTED' files. The error is correctly generated; the run time
 thinks that you are trying to OPEN 'CON' as an unformatted file.

 You also can achieve the desired result (a scratch file for unit 6) by
 using the following:

 OPEN (6,file='junk',form='unformatted',status='scratch')

 Renaming the file during the OPEN is crucial.


 78. "Divide by Zero" Error

 Product Version(s): 4.00A
 Operating System:   MS-DOS
 Flags: ENDUSER | ptr900075 bcp1634 buglist4.00 fixlist4.01
 Last Modified:  1-JUN-1988    ArticleIdent: Q22415

    The following subroutine produces "error F2023: divide by zero"
 during compilation:

    subroutine sub1(cx)
    CHARACTER*(*) cx(2)
    write (*,*) cx
    end

    Microsoft has confirmed this to be a problem in Version 4.00 of the
 FORTRAN Compiler. This problem was corrected in Version 4.01.
    There are two workarounds. The following is one workaround:

    subroutine sub1(cx)
    c
    c Explicitly declare the CHARACTER size
    c
    CHARACTER*72 cx(2)
    write (*,*) cx
    end

    The following is another workaround:

    subroutine sub1(cx)
    CHARACTER*(*) cx(2)
    c
    c  Use an implied-DO WRITE statement
    c
    write (*,*) (cx(i),i=1,2)
    end


 79. INQUIRE Versus -4I2

 Product Version(s): 4.00a
 Operating System:   MS-DOS
 Flags: ENDUSER | ptr900086 bcp1615 buglist4.00 fixlist4.01
 Last Modified:  1-JUN-1988    ArticleIdent: Q22426

    When compiled with -4I2, the following program:

            CHARACTER*25 fname
            open (1,file='test1')
            open (3,file='test3')
            do 100 i=1,4
            inquire (unit=i,name=fname)
            write (*,*) 'unit=',i,' fname=',fname
    100     continue
            end

 should produce the following output:

    unit=          1 fname=test1
    unit=          2 fname=UNKNOWN
    unit=          3 fname=test3
    unit=          4 fname=UNKNOWN

 but instead prints as follows:

    unit=      16138 fname=test1

    Microsoft has confirmed this to be a problem in Version 4.00 of the
 FORTRAN Compiler. It was corrected in Version 4.01.

    INQUIRE is using two bytes of stack space whenever one of the
 specifiers that return a CHARACTER string (such as the NAME=
 specifier) is given. When you compile with -4I2 and maximum
 optimization, the resulting corruption of the stack becomes apparent
 because the SI register is destroyed and, unfortunately in this case,
 SI is used to store the DO loop index.
    The following are two workarounds:

    1. Compile without -4I2.
    2. Compile with -Odct (no loop optimization).


 80. Wrong Default of SHARE=

 Product Version(s): 4.00A
 Operating System:   MS-DOS
 Flags: ENDUSER | ptr900087 bcp1588 buglist4.00 fixlist4.01
 Last Modified:  1-JUN-1988    ArticleIdent: Q22443

    The following program:

    character*30 name,mode,share
    open(1, file ='xxx')
    inquire (unit=1,mode=mode,name=name, share=share)
    write (*,*) 'MODE=[',mode,']'
    write (*,*) 'NAME=[',name,']'
    write (*,*) 'SHARE=[',share,']'
    close (1,status='delete')
    end

 should produce the following output:

    MODE=[READWRITE                     ]
    NAME=[xxx                           ]
    SHARE=[COMPAT                        ]

 but actually prints as follows:

    MODE=[READWRITE                     ]
    NAME=[xxx                           ]
    SHARE=[DENYNONE                      ]

    Microsoft has confirmed this to be a problem in Version 4.00 of the
 FORTRAN Compiler. It was corrected in Version 4.01.


 81. Compile Time Errors F2503/F2506

 Product Version(s): 4.00A
 Operating System:   MS-DOS
 Flags: ENDUSER | ptr900088 bcp1650 buglist4.00 fixlist4.01
 Last Modified: 15-MAR-1988    ArticleIdent: Q22444

 Problem:
    The following program:

       CHARACTER CARD(1),C
       LOGICAL*1 BL,TEST1
       TEST1(C)=LGE(C,'A').AND.LLE(C,'Z')
       bl = TEST1(CARD(is))
       END

 produces the following compilation errors:

    bcp1650.for(4) : error F2503: LGE : incorrect use of intrinsic function
    bcp1650.for(4) : error F2506: cannot convert type to LOGICAL

 Response:
    Microsoft has confirmed this to be a problem in Version 4.00 of the
 FORTRAN Compiler. It was corrected in Version 4.01.
    The workaround for this is to store the value of CARD(IS) in a
 CHARACTER variable and pass it instead of the array element.


 82. Unique Serial Number on Registration Card

 Product Version(s): 4.00 4.01
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified:  7-DEC-1987    ArticleIdent: Q22420

 Problem:
    I am following your instructions to fill out the
 registration card for your FORTRAN Compiler, but I am
 unable to access the 16-digit serial number you request. No
 serial number appears in the right-hand corner.

 Response:
    There is no unique serial number for your FORTRAN
 Compiler (or for any of our compilers). The instructions
 you are referring to pertain to Microsoft Word users only.
 You should skip this part of the registration card.


 83. Compile Time Error F2408

 Product Version(s): 4.00
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist4.00 fixlist4.01
 Last Modified: 27-MAY-1988    ArticleIdent: Q22422

 Question:
    The compiler is erroneously generating error F2408 "too few
 constants to initialize data" for a data statement that uses an
 implied DO loop. Is this a reported problem?

 Response:
    This is a known problem in Version 4.00. It was corrected in
 Version 4.01.
    We have not seen this error message appear erroneously unless other
 errors precede it. Because cascading errors seem to cause this error
 to be generated, correcting the previous errors will eliminate this
 error.


 84. Optimization Bug in Character Transfer

 Product Version(s): 4.00A
 Operating System:   MS-DOS
 Flags: ENDUSER | ptr900080 bcp1626 buglist4.00 fixlist4.01
 Last Modified:  1-JUN-1988    ArticleIdent: Q22506

    The loop optimizer apparently does not recognize that the
 destination CHARACTER array is being loaded in reverse order. It
 generates code assuming that it is a straight CHARACTER block
 transfer.
    The workaround for this problem is to compile with -Od or -Odct
 (suppressing loop optimization).
    Microsoft has confirmed this to be a problem in Version 4.00 of the
 FORTRAN compiler. This problem was corrected in Version 4.01.

    Here is an example of a program that recreates the problem. The
 following program:

       character*1 rd(4),tr(4)
         data rd /'1','2','3','4'/
       do 1 i=1,4
 1     tr(5-i)=rd(i)
         write (*,*) 'tr=<',tr,'>'
       end

 should produce the following output:

    tr=<4321>

 but it actually prints as follows:

    tr=<1>


 85. COMPLEX Constant Folding Problem

 Product Version(s): 4.00A
 Operating System:   MS-DOS
 Flags: ENDUSER | ptr900081 bcp1633 buglist4.00 fixlist4.01
 Last Modified: 28-AUG-1990    ArticleIdent: Q22507

 The answer for "cc" in the program below is incorrect because the
 compiler does not generate the correct constant for use in the
 expression. It is generating a (0.0,0.0) when it should be generating
 a (2.0,0.0).

 The compiler, in some circumstances, is not properly creating
 constants that are calculated from an INTEGER (2) times a COMPLEX.

 There is a workaround for this problem. Do not use INTEGER constants
 as part of a COMPLEX expression. Changing both INTEGER 2s to REAL 2s
 will correct the problem.

 Microsoft has confirmed this to be a problem in version 4.00 of the
 FORTRAN Compiler. This problem was corrected in version 4.01.

 The following program is an example of how to re-create the problem.
 The following program

       complex ca,cb,cc
       r = 1.5
       ca = cmplx(.5,.1)
       cb = (0.,1.)*2*ca*r
       cc = (0.,1.)*ca*2*r
       write (*,*) 'ca=',ca
       write (*,*) 'cb=',cb
       write (*,*) 'cc=',cc
       end

 should produce the following output:

    ca=      (5.000000E-01,1.000000E-01)
    cb=         (-3.000000E-01,1.500000)
    cc=         (-3.000000E-01,1.500000)

 However, it actually prints as follows:

    ca=      (5.000000E-01,1.000000E-01)
    cb=         (-3.000000E-01,1.500000)
    cc=      (0.000000E+00,0.000000E+00)


 86. CHARACTER Functions in WRITE Statements

 Product Version(s): 4.00
 Operating System:   MS-DOS
 Flags: ENDUSER | ptr900083 bcp1638 buglist4.00 fixlist4.01
 Last Modified:  1-JUN-1988    ArticleIdent: Q22508

 Problem:
    The following program:

    character*10 c
    i = 1
    j = 2
    k = 3
    l = 4
    m = 5
    write(*,*)c(i),c(j),c(k),c(l),c(m)
    end
    character*10 function c(ix)
    character*10 ctemp
    write (ctemp,'(5x,i5.5)') ix
    c = ctemp
    end

 should produce the following output:

    00001     00002     00003     00004     00005

 but actually prints as follows:

    00001     00002     00003     00001     00001

 Response:
    You can work around this problem by storing the function results in
 temporary CHARACTER*10 variables and then writing them out instead of
 the functions themselves.
    Microsoft has confirmed this to be a problem in Version 4.00 of the
 FORTRAN Compiler. This problem was corrected in Version 4.01.


 87. Compile Time Error F2529

 Product Version(s): 4.00A
 Operating System:   MS-DOS
 Flags: ENDUSER | ptr900082 bcp1637 buglist4.00 fixlist4.01 fixlist4.01a
 Last Modified: 27-MAY-1988    ArticleIdent: Q22504

    The following program:

         character*1 c(5),d
         logical l,m
         l(d)=(d.eq.'a'.and.d.ne.'d')
         i=5
         m=l(c(i))
         end

 produces the following compilation errors:

 bcp1637.for(19) : error F2529: operands of relation not numeric or character
 bcp1637.for(19) : error F2529: operands of relation not numeric or character

    Microsoft has confirmed this to be a problem in Version 4.00 of the
 FORTRAN Compiler. This problem was corrected in Version 4.01.
    The program fails due to the use of a CHARACTER array element as an
 argument to a LOGICAL statement function that is expecting a single
 character.
    The workaround is to store c(i) in a temporary CHARACTER variable
 and pass the temporary to the function.


 88. Compile Time Error F2734

 Product Version(s): 4.00A
 Operating System:   MS-DOS
 Flags: ENDUSER | ptr900106 bcp1687 buglist4.00 fixlist4.01
 Last Modified: 27-MAY-1988    ArticleIdent: Q22595

 Problem:
    The following program:

 C
         OPEN(11,FILE='TMP',RECL=12,ACCESS='DIRECT',FORM='FORMATTED')
         DO 10 I=1,10
         WRITE(11,'(I5)',REC=I)I
 10      CONTINUE
         DO 20 I=5,15
         READ(11,'(I5)',END=30,REC=I,IOSTAT=N)M
         WRITE(*,*)'Read ',m,' from record ', i,'iostat=',n
 20      CONTINUE
         WRITE(*,*)'No err detected'
         CLOSE (11, STATUS='DELETE')
         STOP
 30      WRITE(*,*)'End found'
         CLOSE (11, STATUS='DELETE')
         END

 causes the following compilation error:

    may29.for(21) : error F2734: END= : illegal when REC= present

 Response:
    Microsoft has confirmed this to be a problem in Version 4.00 of the
 FORTRAN compiler. It was corrected in Version 4.01.
    In Version 4.00, this was expected behavior, conforming to the ANSI
 X3.9-1978 FORTRAN standard. However, since the run time permits a
 direct-access file to be accessed sequentially, it would be convenient
 to be able to detect end-of-file on direct-access files. This is
 corrected in Version 4.01 of the compiler. The compilation error still
 will be given if the program is compiled with the -4Ys ($STRICT)
 option.


 89. WRITE of CHARACTER*(*) Substring

 Product Version(s): 4.00A 4.01
 Operating System:   MS-DOS
 Flags: ENDUSER | ptr900085 bcp1641 buglist4.00 buglist4.01
 Last Modified: 27-MAY-1988    ArticleIdent: Q22509

 Problem:
    The following program

    character*20 c
    c='no time for musicians'
    call s(c)
    end
    subroutine s(c)
    character*(*) c
    write(*,*)c(1:10)
    end

 should print the following:

    no time fo

    However, it actually prints only blanks.

 Response:
    This is a known problem in Versions 4.00 and 4.01.
    The workaround is to declare "c" to be CHARACTER*20 instead of
 CHARACTER*(*) in the subroutine.
    Microsoft is researching this problem and will post new information
 as it becomes available.


 90. Bad Constant Fold of Loop Invariant

 Product Version(s): 4.00A
 Operating System:   MS-DOS
 Flags: ENDUSER | ptr900079 bcp1632 buglist4.00 fixlist4.01
 Last Modified:  1-JUN-1988    ArticleIdent: Q22505

 Problem:
    The following program:

         x = 1.
         y = 1.
         z = 1.
         write (*,*) 'all answers should be 10001'
         do 10 i=1,10000
         x = x+y/z
 10      continue
         print *,x
         end

 should print the following:

    all answers should be 10001
       10001.000000

 but actually prints as follows:

    all answers should be 10001
         151.197500

 Response:
    The .COD file shows that the generated code is trying to calculate
 the final value of X at the point where the source code shows it being
 initialized to 1.0. This would be correct; however, in the first
 step of the calculation, a value is loaded from a temporary that never
 was initialized. Therefore, what finally is stored in X is
 <garbage>*10000+1. In this case X=151.1975. This will vary.
    This problem can be worked around by compiling with -Odclt.
    Microsoft has confirmed this to be a problem in Version 4.00 of the
 FORTRAN compiler. This problem was corrected in Version 4.01.


 91. Compile Time Error F2125

 Product Version(s): 4.00a
 Operating System:   MS-DOS
 Flags: ENDUSER | ptr900084 bcp1640 buglist4.00 fixlist4.01
 Last Modified:  1-JUN-1988    ArticleIdent: Q22510

    The following program produces the following error:

    "bcp1640a.for(4) : error F2125 : BUFF2 : allocation exceeds 64K":

    INTEGER*4 BUFF2(480)
    INTEGER*4 BUFF(18000)
    EQUIVALENCE(BUFF2(1),BUFF(1))
      end

    This problem lies with EQUIVALENCEing a huge array (i.e., more than
 64K) with a "non-huge" array.
    The problem can be worked around by declaring the huge arrays that
 are going to be EQUIVALENCEd before declaring the "non-huge" arrays.
    Microsoft has confirmed this to be a problem in Version 4.00 of the
 FORTRAN Compiler.
    This problem was corrected in Version 4.01.


 92. Errors in ISHFT and ISHL Functions

 Product Version(s): 4.00A
 Operating System:   MS-DOS
 Flags: ENDUSER | ptr900077 bcp1639 buglist4.00 fixlist4.
 Last Modified:  1-JUN-1988    ArticleIdent: Q22517

 Problem:
    The following program:

       integer*2 inta,itemp
       inta=#8000
         call sub (inta)
       itemp=ishft(inta,-2)
         write (*,'(1x,a,z4)') 'should be #2000, is=',itemp
       inta=#8000
         call sub (inta)
       itemp=ishl(inta,-2)
         write (*,'(1x,a,z4)') 'should be #2000, is=',itemp

       inta=#8000
       itemp=ishft(inta,-2)
         write (*,'(1x,a,z4)') 'should be #2000, is=',itemp
       inta=#8000
       itemp=ishl(inta,-2)
         write (*,'(1x,a,z4)') 'should be #2000, is=',itemp
         end
         subroutine sub (ix)
         integer*2 ix
         end

 produces the following output:

    should be #2000, is=E000
    should be #2000, is=E000
    should be #2000, is=E000
    should be #2000, is=E000

 Response:
    There are two separate errors in the above example. Both occur
 because the compiler is converting INTA to be an INTEGER*4 variable.
 This is causing problems for the ISHFT and ISHL functions, which are
 logical shift functions. Logical shifting operands to the right should
 add ("shift in") zero bits to the high-order part of the variable.
    In the first pair of ISHFT/ISHL calls, the answers are calculated
 by calls to a library routine. ITEMP cannot be calculated by the
 compiler because the value of INTA may have been changed in the
 preceding subroutine call.
    The errors in these calls occur because during the setup for the
 calls to the shift routines, INTA is converted from INTEGER*2 to
 INTEGER*4 from the value of #8000 to #FFFF8000; i.e., the upper word
 is sign-extended. Subsequently, when the two-bit right shift is done,
 bits (all of which are set) are shifted into the lower two words.
    The second pair of answers is calculated during compilation and is
 incorrect for the same reason: the answers are treated as four-byte
 integers.
    To work around this problem, compile with the -4I2 option.
    This is a confirmed problem in Version 4.00 of the
 FORTRAN compiler.
    This problem was corrected in Version 4.01.


 93. Linker Cannot Find LLIBFOR7.LIB

 Product Version(s): 4.00 4.01
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 18-OCT-1988    ArticleIdent: Q22588

 Problem:

 I do not have a coprocessor on my system, so I built a FORTRAN library
 with emulator support (LLIBFORE.LIB) using the Setup utility. I am
 using the Version 3.55 Linker that comes with FORTRAN Version 4.00. I
 set my LIB environment variable to C:\FORTRAN\LIB, and when I do DIR
 on this directory, it finds LLIBFORE.LIB. However, when I enter the
 command "FL DEMO.FOR", the linker generates the following warning
 message:

    Warning L4051: LLIBFOR7.LIB: cannot find library

 Response:

 When FL compiles a source file, it places the name of a FORTRAN
 library into the object file that it creates. The library name
 corresponds to the memory-model and floating-point options that you
 specify on the FL command line. If you do not specify any memory-model
 or floating-point options, FL defaults to large-model and coprocessor
 (8087/80287) support, and therefore places the library name
 "LLIBFOR7.LIB" in your object module. When you link the object module,
 the linker looks for a library matching the name embedded in the
 object file. If it finds the library, it automatically links the
 library with the object module.

 Because the command line "FL DEMO.FOR" does not explicitly specify a
 floating-point option, DEMO.OBJ contains the library name
 LLIBFOR7.LIB; that is the library name for which the linker looks.
 Because you did not create a LLIBFOR7.LIB with Setup, the linker
 returns a warning that it cannot find the library.

 Therefore, to link your object files with the LLIBFORE.LIB emulator
 library, you need to specify the floating-point option /FPi or /FPc on
 the FL command line.

 For more information regarding the floating-point options, please
 refer to Page 59 in the user's guide.


 94. Missing Line in Program Listing

 Product Version(s): 4.00
 Operating System:   MS-DOS
 Flags: ENDUSER | docerr
 Last Modified:  7-SEP-1988    ArticleIdent: Q22629

 Problem:

 There is an error in the program listing on Page 332 of the "Microsoft
 FORTRAN Compiler Language Reference" manual. Compiling as is will
 result in a syntax error.

 Response:

 There is a missing line in the program listing. Currently, line 19
 contains the following:

 + CDATE,IMON,IDAY,IYR

 There should be a line before it. The following line will correct the
 syntax error problem.

 WRITE(*,'(1X,A,I2.2,1H-,I2.2,1H-,I4)')


 95. Backspacing Past CR/LF on a Buffer Boundary

 Product Version(s): 4.00a
 Operating System:   MS-DOS
 Flags: ENDUSER | ptr900107 bcp1694 buglist4.00 fixlist4.01
 Last Modified:  1-JUN-1988    ArticleIdent: Q22601

    The program below demonstrates a boundary condition problem. The
 program correctly writes 210 five-byte records (three digits plus
 CR/LF), REWINDs the file, and then proceeds to do a sequence of READ,
 READ, BACKSPACE operations. This process is successful until the 205th
 record. The CR/LF pair that follows the 205th record is split between
 two buffers. When the subsequent BACKSPACE occurs, the run time
 effectively gets "stuck" on the LF in the 206th record. Raising the
 BLOCKSIZE may circumvent the problem; however, more likely, it will
 simply postpone it.
    Microsoft has confirmed this to be a problem in Version 4.00 of the
 FORTRAN compiler. This problem was corrected in Version 4.01.

    The following program:

         open (1,file='bcp1694.dat')
         do 100 i=1,210
           write (1,'(i3)') i
 100     continue
         rewind (1)
         do 200 i=1,210
         read (1,'(i3)') i1
         read (1,'(i3)',end=999) ihold
         backspace 1
         if (i .ge. 200) write (*,*) 'rec #,curr rec #,next rec #=',
      +  i,i1,ihold
 200     continue
 999     continue
         close(1,status='delete')
         end

 should produce the following output:

 rec #,curr rec #,next rec #=        200         200         201
 rec #,curr rec #,next rec #=        201         201         202
 rec #,curr rec #,next rec #=        202         202         203
 rec #,curr rec #,next rec #=        203         203         204
 rec #,curr rec #,next rec #=        204         204         205
 rec #,curr rec #,next rec #=        205         205         206
 rec #,curr rec #,next rec #=        206         206         207
 rec #,curr rec #,next rec #=        207         207         208
 rec #,curr rec #,next rec #=        208         208         209
 rec #,curr rec #,next rec #=        209         209         210

    However, it actually prints the following:

 rec #,curr rec #,next rec #=        200         200         201
 rec #,curr rec #,next rec #=        201         201         202
 rec #,curr rec #,next rec #=        202         202         203
 rec #,curr rec #,next rec #=        203         203         204
 rec #,curr rec #,next rec #=        204         204         205
 rec #,curr rec #,next rec #=        205         205         206
 rec #,curr rec #,next rec #=        206           0         206
 rec #,curr rec #,next rec #=        207           0         206
 rec #,curr rec #,next rec #=        208           0         206
 rec #,curr rec #,next rec #=        209           0         206
 rec #,curr rec #,next rec #=        210           0         206


 96. Using FL with the /NOI Option

 Product Version(s): 4.00
 Operating System:   MS-DOS
 Flags: ENDUSER | docerr
 Last Modified:  7-SEP-1988    ArticleIdent: Q22761

 Question:

 Page 54 in the "Microsoft FORTRAN Optimizing Compiler User's Guide"
 states that FL always uses the /NOI link option in the linking stage.
 I have found that this is not always the case. For example, the
 following command line emits the following /NOI option:

 FL demo

 However, the following command line does not:

 Fl demo.for

 Is this a documentation error?

 Response:

 Yes, this is a documentation error. In the FORTRAN Version 4.00, the
 /NOI switch only is emitted if only object files are specified on the
 FL command line. If only source files (.FOR) are specified, or if a
 mixture of source and object files is specified, the /NOI switch is
 not generated.


 97. REC=1 Should Be RECL=1

 Product Version(s): 4.00 4.01
 Operating System:   MS-DOS
 Flags: ENDUSER | docerr
 Last Modified: 13-JAN-1989    ArticleIdent: Q22788

 Question:

 Is there is a documentation error on Page 121 in the "Microsoft
 FORTRAN Optimizing Compiler Language Reference" manual on the fifth
 line from the bottom? Should "REC=1" should be changed to "RECL=1"?

 Response:

 Yes. "REC=1" should be "RECL=1".


 98. Run Time Error F6419

 Product Version(s): 4.00a
 Operating System:   MS-DOS
 Flags: ENDUSER | ptr900089 bcp1648 buglist4.00 fixlist4.01
 Last Modified:  1-JUN-1988    ArticleIdent: Q22719

    The following program will produce the following error and then may
 hang the computer:

    "F6419 :illegal structure"

       parameter (m = 119, n = 520)
       integer*1 ia(n),ib(n),ja(m),jb(m)
       do 11 j = 1,m
       ja(j) = mod(j,256)
 11    continue
       do 10 i = 1,n
       ia(i) = mod(i,256)
 10    continue
       open (33,file = 'ufseq',form='unformatted',blocksize=512)
       write (33) ja
       write (33) ia
       rewind(33)

       read (33) jb
       do 21 j = 1,m
       if (ja(j).ne.jb(j)) goto 51
 21    continue
       read (33) ib
       do 20 i = 1,n
       if (ia(i).ne.ib(i)) goto 50
 20    continue
       stop 'passed'

 51    write (*,*) ja(i), '.ne.', jb(i)
       write (*,*) 'j = ',j
       stop 'failed'
 50    write (*,*) ia(i), '.ne.', ib(i)
       write (*,*) 'i = ',i
       stop 'failed'
       end

    Microsoft has confirmed this to be a problem in Version 4.00 of the
 FORTRAN Compiler. This problem was corrected in Version 4.01.
    This is one of several possible causes for this error. It is very
 specific: READing an unformatted file that contains a record whose
 "trailer-byte" (a byte containing the length of the preceding record)
 is placed exactly on a buffer boundary (in this case, the 512th byte)
 will cause the error to occur on that record.
    Investigating this error also turned up the fact that the F6419
 error message itself is being truncated. It should read "F6419 :
 illegal structure for unformatted file". The routine that writes the
 error message is losing track of where the message ends.
    Until more is known about the causes for the F6419 error, the
 workarounds remain as follows:

    1. Those who use unformatted files within their programs for the
 purpose of temporary data storage can change the OPEN statement's
 FORM= specifier for their files from 'UNFORMATTED' to 'BINARY'. The
 associated READ and WRITE statements need not be changed.
    2. Those with existing unformatted data files may be able to work
 around this problem by increasing the size of the file's buffer by
 using the BLOCKSIZE= specifier on the OPEN statement.


 99. Zero-Trip Implied-DO in READ

 Product Version(s): 4.00A
 Operating System:   MS-DOS
 Flags: ENDUSER | ptr900101 bcp1680 buglist4.00
 Last Modified: 27-MAY-1988    ArticleIdent: Q22838

 Problem:
    The following program:

       DIMENSION IX(10)
       DO 1000 I=1,10
           IX(I)=I
  1000 CONTINUE
 C
       ISTART=0
       IEND=-1
       WRITE(*,8000)(IX(I),I=ISTART,IEND),778
  8000 FORMAT(8I10)
       END

 should produce the following output:

       778

    However, it actually prints only blanks.

 Response:
    Microsoft is researching this problem and will post new information
 as it becomes available.
    The workaround is to avoid using erroneous values for the loop
 indices.


 100. Run-Time Error F6600

 Product Version(s): 4.00A
 Operating System:   MS-DOS
 Flags: ENDUSER | ptr900100 bcp1682 buglist4.00 fixlist4.01
 Last Modified: 27-MAY-1988    ArticleIdent: Q22837

 Problem:
    The following program:

         character str*10
         call sub1 (str)
         write (*,*) 'str should be 12345, is=<',str,'>'
         end
         subroutine sub1(str)
         character str*(*)
         inum = 12345
         write (str(2:6),'(i5)') inum
         end

 should produce the following output:

    str should be 12345, is=<12345>

    However, it actually prints the following:

    run-time error F6600: WRITE(internal)
    - internal file overflow

 Response:
    Microsoft has confirmed this to be a problem in Version 4.00 of the
 FORTRAN compiler. It was corrected in Version 4.01.
    The problem can be worked around in the following two ways:

    1. In the subroutine, declare STR to be of a fixed size instead of
 CHARACTER*(*).
    2. In the internal WRITE, use STR instead of the substring of STR.


 101. EQUIVALENCE of ENTRY Arguments

 Product Version(s): 4.00A
 Operating System:   MS-DOS
 Flags: ENDUSER | ptr900097 bcp1677 buglist4.00 fixlist4.01
 Last Modified: 27-MAY-1988    ArticleIdent: Q22833

    The following program should fail with a compilation error that
 indicates that you cannot EQUIVALENCE a formal argument:

         subroutine test
         equivalence (a,c)
         entry test1 (a,b)
         c = 1.0
         end

    This is a known problem in Version 4.00 of the FORTRAN Compiler.
 This was corrected in Version 4.01.


 102. Internal Compiler Error: regMD.c 1.74, Line 1204

 Product Version(s): 4.00A
 Operating System:   MS-DOS
 Flags: ENDUSER | ptr900093 bcp1666 buglist4.00 fixlist4.01
 Last Modified:  1-JUN-1988    ArticleIdent: Q22827

    The following program:

         integer*4 comp(2,10)
         integer*2 br(10),locx(10),stor(10),flav(10),age(10)
         do 6 i=1,mpt
            comp(1,i) = (((10*br(i) + locx(i))*10 + stor(i))*10 +
      +                    flav(i))*100 + age(i)
 6          comp(2,i) = i
         end

 produces the following assertion error:

         regMD.c:1.74, line 1204

    This is a known problem in Version 4.00 of the FORTRAN compiler. It
 was corrected in Version 4.01.
    To work around this problem, modify the statement COMP(1,I) = ...,
 as follows:

    1. Assign all of the array references to integer variables.
    2. Use them in place of the array references in the expression.


 103. -4I2 Compiler Hang

 Product Version(s): 4.00A
 Operating System:   MS-DOS
 Flags: ENDUSER | ptr900092 bcp1665 buglist4.00 fixlist4.01
 Last Modified: 27-MAY-1988    ArticleIdent: Q22826

    The following program will hang the compiler if compiled with -4I2:

    50 MANTIS = DINT (.5D0 + DVAL * DTEN ** (SIGNIF-MAGN))
       IF (KTEST)  60, 65, 55
    55 MAGN = MAGN - 1
       GO TO 50
    60 MAGN = MAGN + 1
    65 IF (MAGN .GT. -3 .AND. MAGN .LE. MIN0(WIDTH, SIGNIF+3)) GO TO 70
    70    IF (MAGN .GE. 1) GO TO 75
    75       DO 80 I = 1, MAGN
    80       CONTINUE
       END

    Microsoft has confirmed this to be a problem in Version 4.00 of the
 FORTRAN Compiler. It was corrected in Version 4.01.
    The workaround is to compile with -Odclt or without -4I2.


 104. OPENing an OPEN File

 Product Version(s): 4.00A
 Operating System:   MS-DOS
 Flags: ENDUSER | ptr900118 bcp1620 buglist4.00 fixlist4.01
 Last Modified: 26-MAY-1988    ArticleIdent: Q22818

 Problem:
    The following program:

         character*10 nm
         open(1, file='xxx')
         inquire(1, name=nm)
         write(*,*) nm
         open(1, BLANK='null')
         inquire(1, name=nm)
         write(*,*) nm
         end

 should produce the following output:

 xxx
 xxx

    However, it actually prints the following:

 xxx
 ZZ004413

 Response:
    Microsoft has confirmed this to be a problem in Version 4.00 of the
 FORTRAN compiler. It was corrected in Version 4.01.
    The intent of this program is to change the setting of the BLANK
 specifier on an OPEN file. The run time is CLOSEing the file and then
 OPENing a scratch file that has the correct BLANK setting instead of
 just changing the setting of BLANK.


 105. OPEN(1,FILE= ' ',STATUS=cvar)

 Product Version(s): 4.00A
 Operating System:   MS-DOS
 Flags: ENDUSER | ptr900099 bcp1681 buglist4.00 fixlist4.01
 Last Modified: 26-MAY-1988    ArticleIdent: Q22836

 Problem:
    The following program:

         character*30 stat
         stat = 'UNKNOWN'
         open (1,file=' ',status=stat,iostat=ier)
         write (*,*) 'iostat should be 0, is=',ier
         end

 should produce the following output when given a filename at
 run time:

    iostat should be 0, is=          0

    However, it actually prints the following:

    iostat should be 0, is=       6304 (illegal status value)

 Response:
    Microsoft has confirmed this to be a problem in Version 4.00 of the
 FORTRAN compiler. It was corrected in Version 4.01.
    Whether the contents of STAT are uppercase or lowercase is
 irrelevant: it still does not work. The workaround is to use character
 constants instead of variables.


 106. Compile Error F2609

 Product Version(s): 4.00A
 Operating System:   MS-DOS
 Flags: ENDUSER | ptr900121 bcp1713 buglist4.00 fixlist4.01 fixlist4.01a
 Last Modified: 27-MAY-1988    ArticleIdent: Q22820

    The following program:

       SUBROUTINE LNSR(X,N,D,FUNC,ST0,XS)
       DIMENSION X(N),D(N),XS(N)
       CALL FUNC(XS,N,FOPT,*100)
  100  CALL VEC(X,D,N,ST0,X)
       END
       SUBROUTINE DLNSR(A0,NP,FU0,SFPD,S,ST0,FUNC,NST,A1,KENT)
       EXTERNAL FUNC
       DIMENSION A0(NP),S(NP),A1(NP)
 2000  CALL LNSR(A0,NP,S,FUNC,ST0,A1)
       RETURN
       END

 will produce the following error when compiled:

 error F2609: LNSR : formal argument * : actual not alternate-return label

    Microsoft has confirmed this to be a problem in Version 4.00 of the
 FORTRAN compiler. This problem was corrected in Version 4.01.
    The compiler apparently has confused a function passed as an
 argument for an alternate-return argument. You can work around the
 error, at least in this case, by moving the subroutine LNSR to the end
 of the source file.


 107. Sending a Spawn Command

 Product Version(s): 4.00 4.01 4.10
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 23-MAY-1988    ArticleIdent: Q29561

    The following program is an example of using the spawn function to
 spawn an EXE file that takes no arguments. This example is similiar to
 the one found on Page 298 of the Version 4.01 "Microsoft FORTRAN
 Optimizing Compiler User's Guide."

       interface to integer*2 function spawn
      + [c, varying, alias:'_spawnlp'](mode)
       integer*2 mode
       end

       integer*2 spawn

       write(*,*) 'time to start'
       i = spawn(0, loc('test.exe'c), loc('test'c), int4(0))
       write(*,*) 'its done now'

       stop
       end

    The following three points are important to notice:

    1. An alias (mentioned on Page 297) is needed for names over six
 characters.
    2. Spawn is declared as integer*2.
    3. When sending spawn, 'test.exe' and 'test' must be sent together.


 108. Sending FORTRAN Output to the Printer

 Product Version(s): 4.00 4.01 4.10 5.00 | 4.10 5.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified: 31-OCT-1989    ArticleIdent: Q22830

 Question:

 How do I output data from my FORTRAN program to the printer?

 Response:

 You can access the printer by treating it as a SEQUENTIAL access
 file with one of the following system names:

      PRN
      LPT1
      LPT2
      COM1

 The following example sends output to the printer:

       OPEN(3,FILE='PRN')
       WRITE(3,*)'OUTPUT GOES TO THE PRINTER'
       END

 The OPEN statement associates UNIT #3 with the system file PRN, and
 then opens the printer for output. The UNIT does not have to be #3; it
 can be any UNIT number. The WRITE statement sends output to UNIT #3,
 which is the printer.

 For output to LPT2, status='old' must be included or the run-time
 error "F6415 -file already exists" is generated.

 It should be noted that the system name you use is dependent upon your
 particular system, and you may have to experiment to see which one
 works correctly for you. If you have a serial printer attached to your
 communications port, you should use the MS-DOS MODE command to tell
 the operating system to send printer output to the communications port
 instead of to the regular printer port.


 109. END=var Not Caught by the Compiler

 Product Version(s): 4.00a
 Operating System:   MS-DOS
 Flags: ENDUSER | ptr900114 bcp1703 buglist4.00
 Last Modified:  7-NOV-1988    ArticleIdent: Q22832

 Problem:

 When the following program runs, it hangs:

                    total = 0
                    abc = 200
                    count = 0

    100          count = count + 1
                    read(1,'(i7)',end=abc) value
                    total = total + value
                    goto 100
    200             write(*,*) 'done'
                    stop ' '
                    end

 Response:

 The program is incorrect. Variable ABC cannot be used as the target of
 an END=. END= requires a statement number and ONLY a statement number.
 The program loops because the code for the END= check is not
 generated. The compiler SHOULD be giving a syntax error for the READ
 statement.

 Microsoft has confirmed this to be a problem in Version 4.00. We are
 researching this problem and will post new information as it becomes
 available.

 To solve this problem, correct the syntax.


 110. BACKSPACE Problem

 Product Version(s): 4.00a
 Operating System:   MS-DOS
 Flags: ENDUSER | ptr900098 bcp1679 buglist4.00 fixlist4.01
 Last Modified:  1-JUN-1988    ArticleIdent: Q22834

    In the following program the file is positioned incorrectly,
 apparently in attempting to reposition from the second record to the
 first. Since this problem appears to be related to the file buffering,
 a possible workaround might be to use the BLOCKSIZE= specifier in the
 OPEN statement to increase the buffer size (which, in this case,
 allows the program to work correctly).
    Microsoft has confirmed this to be a problem in Version 4.00 of the
 FORTRAN compiler. This problem was corrected in Version 4.01.

    The following program:

         CHARACTER*80 alpha
         open (1,file='bcp1679.dat')
 5       continue
         read (1,10,end=100) alpha
 10      format (a80)
         write (*,20) alpha
 20      format (1x,a79)
         backspace 1
         read (1,10) alpha
         write (*,20) alpha
         go to 5
 100     continue
         end

 given the following data file:

 111111111111111111111111111111111111111111111111111111111111
 222222222222222222222222222222222222222222222222222222222222
 333333333333333333333333333333333333333333333333333333333333
 444444444444444444444444444444444444444444444444444444444444
 555555555555555555555555555555555555555555555555555555555555
 666666666666666666666666666666666666666666666666666666666666
 777777777777777777777777777777777777777777777777777777777777
 888888888888888888888888888888888888888888888888888888888888
 999999999999999999999999999999999999999999999999999999999999
 000000000000000000000000000000000000000000000000000000000000
 111111111111111111111111111111111111111111111111111111111111
 222222222222222222222222222222222222222222222222222222222222
 333333333333333333333333333333333333333333333333333333333333
 444444444444444444444444444444444444444444444444444444444444
 555555555555555555555555555555555555555555555555555555555555
 666666666666666666666666666666666666666666666666666666666666
 777777777777777777777777777777777777777777777777777777777777
 888888888888888888888888888888888888888888888888888888888888
 999999999999999999999999999999999999999999999999999999999999
 000000000000000000000000000000000000000000000000000000000000
 111111111111111111111111111111111111111111111111111111111111
 222222222222222222222222222222222222222222222222222222222222
 333333333333333333333333333333333333333333333333333333333333
 444444444444444444444444444444444444444444444444444444444444
 555555555555555555555555555555555555555555555555555555555555
 666666666666666666666666666666666666666666666666666666666666
 777777777777777777777777777777777777777777777777777777777777
 888888888888888888888888888888888888888888888888888888888888
 999999999999999999999999999999999999999999999999999999999999
 000000000000000000000000000000000000000000000000000000000000
 111111111111111111111111111111111111111111111111111111111111
 222222222222222222222222222222222222222222222222222222222222
 333333333333333333333333333333333333333333333333333333333333
 444444444444444444444444444444444444444444444444444444444444
 555555555555555555555555555555555555555555555555555555555555
 666666666666666666666666666666666666666666666666666666666666
 777777777777777777777777777777777777777777777777777777777777
 888888888888888888888888888888888888888888888888888888888888
 999999999999999999999999999999999999999999999999999999999999
 000000000000000000000000000000000000000000000000000000000000

 should produce the following output:

 [encoded data, 4800 characters]

    However, it actually prints:

 111111111111111111111111111111111111111111111111111111111111
 444444444444444444444444444444444444444444444444444444444444
 555555555555555555555555555555555555555555555555555555555555
 555555555555555555555555555555555555555555555555555555555555
 666666666666666666666666666666666666666666666666666666666666
 666666666666666666666666666666666666666666666666666666666666
 777777777777777777777777777777777777777777777777777777777777
 777777777777777777777777777777777777777777777777777777777777
 888888888888888888888888888888888888888888888888888888888888
 888888888888888888888888888888888888888888888888888888888888
 999999999999999999999999999999999999999999999999999999999999
 999999999999999999999999999999999999999999999999999999999999
 000000000000000000000000000000000000000000000000000000000000
 000000000000000000000000000000000000000000000000000000000000


 111. Direct Access REC= -1

 Product Version(s): 4.00A
 Operating System:   MS-DOS
 Flags: ENDUSER | ptr900105 bcp1691 buglist4.00 fixlist4.01
 Last Modified: 26-MAY-1988    ArticleIdent: Q22835

 Problem:
    The following program:

         character*8 junk
         open (1,file='may28.dat',access='direct',recl=8)
         write (1,rec=1) 'Stuff'
         close(1)
         open (1,file='may28.dat',access='direct',recl=8)
         read (1,rec=  0,iostat=ier) junk
         write (*,*) 'For rec=  0, iostat should be 6311, and is=',ier
         read (1,rec= -1,iostat=ier) junk
         write (*,*) 'For rec= -1, iostat should be 6311, and is=',ier
         read (1,rec= -2,iostat=ier) junk
         write (*,*) 'For rec= -2, iostat should be 6311, and is=',ier
         close (1,status='delete')
         end

 should produce the following output:

    For rec=  0, iostat should be 6311, and is=       6311
    For rec= -1, iostat should be 6311, and is=       6311
    For rec= -2, iostat should be 6311, and is=       6311

    However, it actually prints the following:

    For rec=  0, iostat should be 6311, and is=       6311
    For rec= -1, iostat should be 6311, and is=          0
    For rec= -2, iostat should be 6311, and is=       6311

 Response:
    Microsoft has confirmed this to be a problem in Version 4.00 of the
 FORTRAN Compiler. It was corrected in Version 4.01.
    The run time seems to treat the REC = -1 case exactly the same as
 if the REC= were not there, i.e., it reads the next record.


 112. Expressions in IF Statements

 Product Version(s): 4.00A
 Operating System:   MS-DOS
 Flags: ENDUSER | ptr900096 bcp1676 buglist4.00 fixlist4.01
 Last Modified: 26-MAY-1988    ArticleIdent: Q22831

 Problem:
    The following program:

         xmax = 14.8
         do 30 i = 1,20
         if (xmax .le. i*5.) then
                 write (*,*) 'i should be 3, is=',i
                 go to 31
         endif
 30      continue
         stop 'error'
 31      stop
         end

 should produce the following output:

 i should be 3, is=          3
 Stop - Program terminated.

    However, it actually prints the following:

 i should be 3, is=         15
 Stop - Program terminated.

 Response:
    Microsoft has confirmed this to be a problem in Version 4.00 of the
 FORTRAN compiler. It was corrected in Version 4.01.
    Within the DO loop, the expression i*5. is never calculated. What
 is being compared against XMAX is i, not i*5; therefore, the loop is
 terminated after 15 iterations instead of three.
    There are a number of workarounds, as follows:

    1. Compile with -Odclt.
    2. Enclose the expression i*5. in parentheses.
    3. Set a temporary integer variable equal to i, and use it in place
 of i within the loop.


 113. HUGE Arrays on ENTRY Statements

 Product Version(s): 4.00A 4.01
 Operating System:   MS-DOS
 Flags: ENDUSER | ptr900094 bcp1671 buglist4.00 buglist4.01
 Last Modified: 27-MAY-1988    ArticleIdent: Q22828

 Problem:
    The following program:

         dimension x(20000)
         do 100 i=1,20000
           x(i) = i
 100     continue
         n = 20000
         write (*,*) 'in main        ',1,x(1),n,x(n)
         call sub2ad (x,n)
         call sub3as (x,n)
         end
         subroutine sub2x
         dimension y(n)
         entry sub2ad (y,n)
         write (*,*) 'at entry sub2ad',1,y(1),n,y(n)
         end
         subroutine sub3x
         dimension y(*)
         entry sub3as (y,n)
         write (*,*) 'at entry sub3as',1,y(1),20000,y(20000)
         end

 should produce the following output:

 in main                  1        1.000000       20000    20000.000000
 at entry sub2ad          1        1.000000       20000    20000.000000
 at entry sub3as          1        1.000000       20000    20000.000000

    However, it actually prints the following:

 in main                  1        1.000000       20000    20000.000000
 at entry sub2ad          1        1.000000       20000     3616.000000
 at entry sub3as          1        1.000000       20000     3616.000000

 Response:
    This is a known problem in Versions 4.00 and 4.01.
    The only workaround is to declare the arguments in the SUBROUTINE
 header.
    Microsoft is researching this problem and will post new information
 as it becomes available.


 114. Internal READ from Substring

 Product Version(s): 4.00a
 Operating System:   MS-DOS
 Flags: ENDUSER | ptr900122 bcp1717 buglist4.00 fixlist4.01
 Last Modified:  1-JUN-1988    ArticleIdent: Q22819

    The following program:

    character*15 ln
    ln = '  1234'
    n1 = 1
    n2 = 8
    read (ln(1:8),'(i10)') ival
    write (*,*) ' ln(1:8) ival should be 1234, is=',ival
    read (ln(1:n2),'(i10)') ival
    write (*,*) ' ln(1:n2) ival should be 1234, is=',ival
    read (ln(n1:8),'(i10)') ival
    write (*,*) ' ln(n1:8) ival should be 1234, is=',ival
    read (ln(n1:n2),'(i10)') ival
    write (*,*) ' ln(n1:n2) ival should be 1234, is=',ival
    end

 should produce the following output:

    ln(1:8) ival=       1234
    ln(1:n2) ival=       1234
    ln(n1:8) ival=       1234
    ln(n1:n2) ival=       1234

  however, it actually prints the following:

    ln(1:8) ival=       1234
    ln(1:n2) ival=          0
    ln(n1:8) ival=       1234
    ln(n1:n2) ival=       1234

    This is a known problem in Version 4.00.
    The error seems to occur only when READing from a substring of an
 internal file where the substring is of the form STR(const:var).
    This problem was corrected in Version 4.01 of the FORTRAN compiler.


 115. Type Coercion within Intrinsics

 Product Version(s): 4.00A
 Operating System:   MS-DOS
 Flags: ENDUSER | ptr900143 bcp1743 buglist4.00 fixlist4.01
 Last Modified: 26-MAY-1988    ArticleIdent: Q22998

 Problem:
    The following program:

         integer*4 pos,pa
         data n /30000/, pos /60413/, pa /1/
         m = min0(n,pos-pa+1)
         write (*,*) 'm=',m
         write (*,*) 'min0(n,pos-pa+1)=',min0(n,pos-pa+1)
         end

 produces the following output if compiled with the option -4I2:

 m=      -5123
 min0(n,pos-pa+1)=      30000

 instead of the following correct output:

 m=      30000
 min0(n,pos-pa+1)=      30000

 Response:
    Microsoft has confirmed this to be a problem in Version 4.00 of the
 FORTRAN compiler. It was corrected in Version 4.01.
    The easiest workaround is to compile without using the -4I2 option.


 116. Run-Time Error M6101

 Product Version(s): 4.00A
 Operating System:   MS-DOS
 Flags: ENDUSER | ptr900133 bcp1742 buglist4.00 fixlist4.01
 Last Modified: 26-MAY-1988    ArticleIdent: Q22997

 Problem:
    The following program:

         dimension a(0:100), b(0:100)
         n = 100
         do 1 i=1,n
         fi = float(i)
         arg = fi/3.
         a(i) = sin(arg) - sin(2.*arg) - sin(5.*arg)
         b(i) = cos(arg) + cos(2.*arg) + cos(5.*arg)
 1       continue
         end

 produces the following run-time error:

    run-time error M6101: MATH
    - floating-point error: invalid

 Response:
    Microsoft has confirmed this to be a problem in Version 4.00 of the
 FORTRAN compiler. It was corrected in Version 4.01.
    You can work around the problem by compiling with -Od or -Odlt.


 117. Huge .LST Files

 Product Version(s): 4.00A
 Operating System:   MS-DOS
 Flags: ENDUSER | ptr900130 bcp1735 buglist4.00 fixlist4.01
 Last Modified: 26-MAY-1988    ArticleIdent: Q22993

 Problem:
    The following program, compiled with the -Fs option, produces an
 .LST file that exceeds 260,000 characters in size:

 $linesize:132
 $page
       end

 Response:
    Microsoft has confirmed this to be a problem in Version 4.00 of the
 FORTRAN compiler. It was corrected in Version 4.01.
    The workaround is to use a value of $LINESIZE that is less than or
 equal to 127 characters.


 118. Multiple CHAR Parameter Lengths Confused

 Product Version(s): 4.00A
 Operating System:   MS-DOS
 Flags: ENDUSER | ptr900127 bcp1690 buglist4.00 fixlist4.01
 Last Modified: 26-MAY-1988    ArticleIdent: Q22943

 Problem:
    The following program:

         character*2 y
         CALL x('a',y('12'),'tyu')
         END
         subroutine x(c1,c2,c3)
         character*(*) c1,c2,c3
         write (*,*) 'c1 should be a, is =<',c1,'>'
         write (*,*) 'c2 should be 12, is =<',c2,'>'
         write (*,*) 'c3 should be tyu, is =<',c3,'>'
         end
         character*2 function y (ch)
         character*(*) ch
         y = ch
         end

 should print the following:

 c1 should be a, is =<a>
 c2 should be 12, is =<12>
 c3 should be tyu, is =<tyu>

    However, it actually prints the following:

 c1 should be a, is =<a1>
 c2 should be 12, is =<1>
 c3 should be tyu, is =<ty>

 Response:
    Microsoft has confirmed this to be a problem in Version 4.00 of the
 FORTRAN compiler. It was corrected in Version 4.01.
    This error will occur only if more than one CHARACTER argument is
 passed. There is no workaround.


 119. Error Message Positions Versus $INCLUDE Files

 Product Version(s): 4.00a
 Operating System:   MS-DOS
 Flags: ENDUSER | ptr900131 bcp1736 buglist4.00a fixlist4.01
 Last Modified:  1-JUN-1988    ArticleIdent: Q22994

    The following program:

    $include:'test'
            hgjfdhgjkfdhgjkf
            end

 has the following $INCLUDE file (test):

         integer x
         integer y
         integer z
         integer a
         integer b
         integer c

    The program has a syntax error on line 2 of the main program. If
 option -Fs is used, the error message will appear under line 2 of the
 $INCLUDE file ("integer y") in the .LST file.
    This was a confirmed problem in Version 4.00a.
    This problem was corrected in Version 4.01.
    There is no workaround.


 120. Optimization Problem

 Product Version(s): 4.00A
 Operating System:   MS-DOS
 Flags: ENDUSER | ptr900132 bcp1741 buglist4.00 fixlist4.01 fixlist4.01a
 Last Modified: 26-MAY-1988    ArticleIdent: Q22996

 Problem:
    The following program:

         nmin = 1
         nmax = 2
         do 120 i=1,2
         write (*,*) 'nmin=',nmin
         do 110 m=nmin,2,nmax
         write(*,*) 'm,nmin=',m,nmin
 110     continue
         nmin =2
         nmax = nmax+1
 120     continue
         end

 produces the following correct output when compiled with -Od:

 nmin=          1
 m,nmin=          1           1
 nmin=          2
 m,nmin=          2           2

    However, when compiled with the default option, the program prints
 the following:

 nmin=          2
 m,nmin=          2           2
 nmin=          2
 m,nmin=          2           2

 Response:
    Microsoft has confirmed this to be a problem in Version 4.00 of the
 FORTRAN compiler. This problem was corrected in Version 4.01.
    You can work around this problem by compiling with option -Od or
 -Odct.


 121. Integer Overflow Is Not Being Checked

 Product Version(s): 4.10
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 17-MAR-1988    ArticleIdent: Q27850

 Problem:
    The following code will not check for integer overflow correctly.

        integer*4 d
        real*4 x
        d = 13
        x = 1123.000
        write(*,1) x/10**d
        write(*,1) x/10.0**d
  1     format(f40.20)
        stop

 The first write statement will give an incorrect answer because of
 unchecked integer overflow.

 Response:
    Microsoft is researching this problem and will post new information
 as it becomes available.


 122. Direct Access File Problem

 Product Version(s): 4.00A
 Operating System:   MS-DOS
 Flags: ENDUSER | ptr900129 bcp1732 buglist4.00 fixlist4.01
 Last Modified: 26-MAY-1988    ArticleIdent: Q22945

 Problem:
    The program below attempts to execute the following steps:

    1. OPEN a direct access formatted file.
    2. WRITE to it until an error occurs (which, presumably, will be an
 error 6422 - no space left on device).
    3. ReWRITE the first record (with content that differs from what
 was first put there).
    4. CLOSE the file, OPEN it as a formatted sequential file, and READ
 the first record.
    5. Check to make sure that the first record contains the
 information put there following the "no space" error.

    The program is as follows:

         character*10000 line
         n = 1
         open (1,file='test.dat',access='direct',recl=10000,
      +  form='formatted')
 100     continue
         write (1,'(a)',rec=n,err=900,iostat=ier) line
         n = n+1
         go to 100
 900     continue
         write (1,'(a,i3)',rec=1,err=999) 'Disk full at record=',n-1
 999     continue
         close (1)
         open (1,file='test.dat')
         read (1,'(A)') line
         if (line(:9) .eq. 'Disk full') then
           write (*,*) 'Test passed'
         else
           write (*,*) 'Test failed'
         endif
         close (1,status='delete')
         end

    The following output should be produced:

    Test passed

    However, the following actually is printed:

    Test failed

 Response:
    Microsoft has confirmed this to be a problem in Version 4.00 of the
 FORTRAN compiler. It was corrected in Version 4.01.
    The "Test failed" message is printed because the run time produces
 an "error F6601 - direct record overflow" when Step 3 above is
 attempted. The error apparently is caused by a failure to update a
 buffer pointer following the "no space" error. There is no workaround.


 123. Inquire by File on Devices

 Product Version(s): 4.00a
 Operating System:   MS-DOS
 Flags: ENDUSER | ptr 900150 bcp 1772 buglist4.00 fixlist4.10
 Last Modified: 30-SEP-1988    ArticleIdent: Q23118

 The program below does not produce the correct output.

 Microsoft has confirmed this to be a problem in Version 4.00. This
 problem was corrected in Version 4.10.

 The following program demonstrates the problem:

         character*10 dev(5)
         logical test
         dev(1) = 'com1'
         dev(2) = 'prn'
         dev(3) = 'aux'
         dev(4) = 'nul'
         dev(5) = 'con'
         do 100 i=1,5
           inquire (file=dev(i),exist=test)
           if (test) write (*,*) 'file ',dev(i),' exists'
 100     continue
         end

 The program should produce the following output; however, it does not
 print anything:

 file com1       exists
 file prn        exists
 file aux        exists
 file nul        exists
 file con        exists


 124. F1901 Compile Error Caused by Many Equivalences

 Product Version(s): 4.01 4.10
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 16-JUN-1988    ArticleIdent: Q27986

    The F1901 "program too large for memory" error message occurs when
 compiling a FORTRAN program consisting of 55 equivalences. The
 following partial code demonstrates this problem by equivalencing two
 arrays.
    However, since arrays are required to be contiguous in memory, you
 need only equivalence the first element of the two arrays to
 accomplish the same effect, thereby avoiding the error.
    The following code fragment demonstrates this workaround for
 equivalencing the two arrays in the program below:

    REAL*8 A(200)
    REAL*8 B(200)
    EQUIVALENCE (A(1),B(2))
    END

    The other equivalences are not necessary. This problem does not
 occur with fewer equivalences. Another program shows this problem
 after 63 equivalences. This problem is also dependent on the size of
 the program and the code.
    Microsoft is researching this problem and will post new information
 as it becomes available.

    The following code demonstrates the problem:

       REAL*8    A(200)
       REAL*8    B(200)
       EQUIVALENCE
      +(A( 1),B( 1)),
      +(A( 2),B( 2)),
      +(A( 3),B( 3)),
             .
             .
             .
      +(A(54),B(54)),
      +(A(55),B(55))
       END


 125. FORMAT Can Give Output of Negative Zero

 Product Version(s): 4.01 4.10 | 4.10
 Operating System:   MS-DOS    | 4.10
 Flags: ENDUSER |
 Last Modified: 19-APR-1988    ArticleIdent: Q27988

    The following program:

       REAL*8 RR(6)
       RR(1)=-0.00004999D0
       RR(2)=-0.00005000D0
       RR(3)=-0.00005100D0
       RR(4)=-0.00000999D0
       RR(5)=-0.00001000D0
       RR(6)=-0.00001001D0
       WRITE(*,911) RR
 911   FORMAT(/' RR :',6F10.4)
       END

 gives the following output:

 RR :    -.0000   -.0001   -.0001    .0000   -.0000   -.0000

 with negative zeros as output.

 Response:
    Microsoft is researching this problem and will post new information
 as it becomes available.


 126. Optimizer Deleting EQUIVALENCEd Variable Assignment

 Product Version(s): 4.00a
 Operating System:   MS-DOS
 Flags: ENDUSER | ptr900138 bcp1751 buglist4.00 fixlist4.01
 Last Modified:  1-JUN-1988    ArticleIdent: Q23262

 Problem:
    The function of the following program is to sum four UNSIGNED
 two-byte integers (65535, 65534, 65533, and 65532) and place the
 result in a four-byte integer variable as in the following example:

         implicit integer*2 (a-z)
         dimension buf(4),lc2(2)
         integer*4 lc4,tot4
         equivalence (lc2,lc4)
         data buf /-1,-2,-3,-4/
         lc2(2) = 0
         do 10 i = 1,4,2
         lc2(1) = buf(i)
         tot4 = tot4+lc4
         lc2(1) = buf(i+1)
         tot4 = tot4+lc4
 10      continue
         write (*,*) 'tot4 should be 262134, is=',tot4
         end

    It should produce the following output:

 tot4 should be 262134, is=     262134

    However, the following actually is printed:

 tot4 should be 262134, is=     196600

 Response:
    Microsoft has confirmed this to be a problem in Version 4.00 of the
 FORTRAN compiler. This problem was corrected in Version 4.01.
    The only workaround is to disable optimization by compiling with
 option -Od.


 127. Optimization Problem

 Product Version(s): 4.00A
 Operating System:   MS-DOS
 Flags: ENDUSER | ptr900156 bcp1783 buglist4.00
 Last Modified:  2-MAY-1988    ArticleIdent: Q23264

 Problem:
    The following program:

         integer id(2)
         alat = 34.55555555
         call ddms (alat,id)
         end
         subroutine ddms (alat,id)
         integer id(2)
         real*4 rl(2)
         rl(1) = alat
         do 10 k=1,1
           rll = rl(k)
           id(k) = rll
           d = id(k)
           diff = rll-d
           write(*,*) 'diff should be 5.555573E-01, is=',diff
 10      continue
         end

 should produce the following output:

 diff should be 5.555573E-01, is=   5.555573E-01

    However, it actually prints the following:

 diff should be 5.555573E-01, is=   0.000000E+00

 Response:
    Microsoft has confirmed this to be a problem in Version 4.00 of the
 FORTRAN compiler. This problem was corrected in Version 4.01.
    The only workaround is to compile with -Od.


 128. Incorrect Code Deletion

 Product Version(s): 4.00a
 Operating System:   MS-DOS
 Flags: ENDUSER | ptr900153 bcp1778 buglist4.00 fixlist4.01
 Last Modified:  1-JUN-1988    ArticleIdent: Q23265

    The following program:

         integer*4 pytab(300)
         common /pytab/ pytptr,pytab
         l1 = 5
         l2 = 5
         pytptr = 1
         dv = 7
         pytab(pytptr) = dv
         pytab(pytptr) = ior(ishft(pytab(pytptr),14),l1)
         pytab(pytptr) = ior(ishft(pytab(pytptr),14),l2)
         write (*,'(1x,a,z8)') 'answer should be 0x70014005, is=',pytab(1)
         end

 should produce the following output:

 answer should be 0x70014005, is=70014005

    However, it actually prints the following:

 answer should be 0x70014005, is=00014005

    Microsoft has confirmed this to be a problem in Version 4.00 of the
 FORTRAN compiler. This problem was corrected in Version 4.01.
    You may work around this problem by compiling with -Od or -Odlt
 (loop optimization but no common subexpression elimination).


 129. NEAR Attribute in COMMON

 Product Version(s): 4.00a
 Operating System:   MS-DOS
 Flags: ENDUSER | ptr900140 bcp1756 buglist4.00 fixlist4.01
 Last Modified:  1-JUN-1988    ArticleIdent: Q23266

    The following program is broken into two files and compiled
 separately:

            implicit INTEGER*2 (a-z)
            common /ccc/ ia,ib,ic
            ix = 0
            ia = 5
            ib = 7
            write (*,100) 'default data segment=',locfar(ix)
    100     format (1x,a,z8)
            write (*,100) 'main program COMMON /ccc/ segment=',
         +  locfar(ia)
            call junk
            write (*,*) ia,' plus ',ib,' should be 12, is=',ic
            end
            subroutine junk
            implicit INTEGER*2 (a-z)
            common /ccc[near]/ia,ib,ic
            write (*,100) 'subroutine COMMON /ccc/ segment=',
         +  locfar(ia)
    100     format (1x,a,z8)
            ic = ia+ib
            end

 It should produce the following output:

    default data segment=8CD10842
    main program COMMON /ccc/ segment=8CD10000
    subroutine COMMON /ccc/ segment=8CD10000
              5 plus           7 should be 12, is=         12

 However, it actually prints the following:

    default data segment=8CD10842
    main program COMMON /ccc/ segment=8CD00000
    subroutine COMMON /ccc/ segment=8CD10000
              5 plus           7 should be 12, is=          0

    Microsoft has confirmed this to be a problem in Version 4.00 of the
 FORTRAN compiler. This problem was corrected in Version 4.01.

    The following are two workarounds:

    1. Specify all the occurrences of the COMMON block to be NEAR.
    2. Specify the first occurrence of the COMMON block in each source
 file to be NEAR.


 130. C and ALIAS Attributes

 Product Version(s): 4.00a
 Operating System:   MS-DOS
 Flags: ENDUSER | ptr900154 bcp1779 buglist4.00
 Last Modified: 11-OCT-1988    ArticleIdent: Q23267

 Question:

 The following program should enable you to link to the C routine named
 csub.c, but you will receive an "unresolved external" error when you
 LINK:

        interface to integer*2 function isub[alias:'CSUB',c] (y)
        integer*2 y
        end

        integer*2 isub
        i = isub(j)
        end

 Response:

 When used together, the resulting name should be lowercase and should
 be preceded by an underscore. Currently, whatever is specified in the
 ALIAS is EXACTLY what you will find in the generated code. The only
 workaround is to modify the alias by inserting the underscore
 character before the name, and changing the name to lowercase letters.


 131. Bad "Type" Information in .LST File

 Product Version(s): 4.00a
 Operating System:   MS-DOS
 Flags: ENDUSER | ptr900149 bcp1771 buglist4.00 fixlist4.01
 Last Modified:  1-JUN-1988    ArticleIdent: Q23269

    The problem program is as follows:

         logical*1 l
         l = .true.
         end

    This produces the following source listing file, (heading omitted
 on purpose):

         1         logical*1 l
         2         l = .true.
         3         end

 main  Local Symbols

 Name                      Class   Type              Size   Offset

 L . . . . . . . . . . . . local   LOGICAL*4            1    0000

 Global Symbols

 Name                      Class   Type              Size   Offset

 main. . . . . . . . . . . FSUBRT  ***                ***    0000

 Code size = 0018 (24)
 Data size = 0000 (0)
 Bss size  = 0001 (1)

 No errors detected

    Microsoft has confirmed this to be a problem in Version 4.00 of the
 FORTRAN compiler. This problem was corrected in Version 4.01.


 132. Logical*1 Versus Equivalence

 Product Version(s): 4.00a
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist4.00 fixlist4.01
 Last Modified:  1-JUN-1988    ArticleIdent: Q23277

    The following program:

        logical*1 newflag(5),flag1,flag2,flag3,flag4,flag5
        common /findex/ flag1,flag2,flag3,flag4,flag5
        equivalence (newflag,flag1)
        flag3 = .true.
        if (flag3) write (*,*) 'flag3 is true'
        if (newflag(3)) write (*,*) 'newflag(3) is true'
        write (*,*) newflag(1),flag1
        write (*,*) newflag(2),flag2
        write (*,*) newflag(3),flag3
        write (*,*) newflag(4),flag4
        write (*,*) newflag(5),flag5
        flag1 = .true.
        if (flag1) write (*,*) 'flag1 is true'
        if (newflag(1)) write (*,*) 'newflag(1) is true'
        write (*,*) newflag(1),flag1
        write (*,*) newflag(2),flag2
        write (*,*) newflag(3),flag3
        write (*,*) newflag(4),flag4
        write (*,*) newflag(5),flag5
        end
        block data
        logical*1 newflag(5),flag1,flag2,flag3,flag4,flag5
        common /findex/ flag1,flag2,flag3,flag4,flag5
        data flag1,flag2,flag3,flag4,flag5
      +    /.false.,.false.,.false.,.false.,.false./
        end

    should generate the following output:

    flag3 is true
    newflag(3) is true
    F F
    F F
    T T
    F F
    F F
    flag1 is true
    newflag(1) is true
    T T
    F F
    T T
    F F
    F F

    however, the following output is printed:

    flag3 is true
    F F
    F F
    F T
    F F
    T F
    flag1 is true
    newflag(1) is true
    T T
    F F
    F T
    F F
    T F

    Microsoft has confirmed this to be a problem in Version 4.00 of the
 FORTRAN compiler. This problem was corrected in Version 4.01.

    This problem seems only to affect equivalence between LOGICAL*1
 items. The easiest way to work around this problem is to use LOGICAL*2
 or LOGICAL*4.


 133. NINT Functions in Expressions

 Product Version(s): 4.00a
 Operating System:   MS-DOS
 Flags: ENDUSER | ptr900152 bcp1775 buglist4.00a fixlist4.01
 Last Modified:  1-JUN-1988    ArticleIdent: Q23279

    The following program:

    call sub (x,y,z)
    write (*,*) '2000-240 should be 1760, is=',nint(x)-nint(y*z)
    end
    subroutine sub (x,y,z)
    x = 2000.
    y = .12
    z = 2000.
    end

    should produce the following message:

    "2000-240 should be 1760, is=1760".

    however, it prints as follows:

    "2000-240 should be 1760, is=-31067048"?

    This is a confirmed problem with Version 4.00a.
    This problem was corrected in Version 4.01.

    After computing NINT(Y*Z), the result of 240 is stored temporarily
 in the BX and CX registers. Unfortunately, the NINT function uses BX
 and CX. Therefore, after the calculation of NINT(X), the value that
 would have been subtracted from NINT(X) has been destroyed.
    You should be able to work around this problem by storing NINT(X)
 and NINT(Y*Z) in temporary integer variables and writing the temporary
 variables.


 134. Compile Time Error F1035 with $DEBUG

 Product Version(s): 4.00A
 Operating System:   MS-DOS
 Flags: ENDUSER | ptr900139 bcp1753 buglist4.00 fixlist4.01 fixlist4.01a
 Last Modified: 27-MAY-1988    ArticleIdent: Q23263

    The following program will produce error message F1035, "Expression
 is too complex":

 $DEBUG
         COMMON Y
       DIMENSION Y(1000),L(25)
    75 CALL DATAI(Y(L(1)),Y(L(2)),Y(L(3)),Y(L(4)),Y(L(5)),Y(L(6)),Y(L(7))
      1,Y(L(8)),Y(L(9)),Y(L(15)),Y(L(16)),Y(L(17)),Y(L(19)),Y(L(23)),Y(L(
      224)),Y(L(25)),AWELL,
      &  Y(LCSS),Y(LHSS),
      &   I0,J0,K0,IK,JK,K5,IP,JP,IQ,JQ,KQ,1,
      &   DUM1,IDUM1,ADUM1,IDUM2,IDUM3,DUM,IDUM4)
        END

    Microsoft has confirmed this to be a problem in Version 4.00 of the
 FORTRAN compiler. This problem was corrected in Version 4.01.

    For this error to occur, the $DEBUG must be used and the array Y
 must not be in DGROUP (the default data segment). In this example, the
 error disappears if just the COMMON statement is removed, unless the
 size of Y is increased to the point at which the array is removed from
 the default data segment for exceeding the "data threshold" defined by
 the -Gt compiler option. (If omitted, this option is preset to 32767
 bytes.) Probably the easiest solution is to compile without the $DEBUG
 option.


 135. Run-Time Error M6103 with -FPa

 Product Version(s): 4.00a
 Operating System:   MS-DOS
 Flags: ENDUSER | ptr900146 bcp1765 buglist4.00 fixlist4.01
 Last Modified:  1-JUN-1988    ArticleIdent: Q23276

    The following program:

        x = 1234.5678
        call strngf (x,4,0)
        end
        subroutine strngf (x,np,ijust)
        character is
        real pwr10(7), pwr210(6)
        data pwr10 /1.e6,1.e5,1.e4,1.e3,1.e2,1.e1,1.e0/
        data pwr210 /1.e-1,1.e-2,1.e-3,1.e-4,1.e-5,1.e-6/
        x2 = abs(x)+(pwr210(np+1)*5.)
        rem = amod(x2,1.)
        write (*,'(a,\)') ' answer should be 5677, is='
        do 20 i=1,np
          n3 = amod((rem/pwr210(i)),10.)
          call bout (n3+48)
 20     continue
        write (*,*)
        end
        subroutine bout (ch)
        character ch
        write (*,'(a,\)') ch
        end

 should produce the output "answer should be 5677, is=5678". However,
 it prints the following:

    answer should be 5677, is=5
    run-time error M6103: MATH
    - floating-point error: divide by 0

    Microsoft has confirmed this to be a problem in Version 4.00 of the
 FORTRAN compiler. It was corrected in Version 4.01. The workaround is
 to compile with either -Od or -Odct.


 136. Piping Not Supported When Using Pause Command in FORTRAN 4.x

 Product Version(s): 4.x
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 19-APR-1988    ArticleIdent: Q28084

    Using FORTRAN Version 3.x and the Pause command, I was able to use
 DOS piping functions. However, when I recompiled under FORTRAN 4.x and
 ran the program piping in its input, I got a run-time error saying
 that the end-of-file was encountered when I hit the pause statement.

 Response:
    The Pause function is operationally different between FORTRAN 3.x
 and 4.x. FORTRAN 3.x allowed piping, but Pause command piping is no
 longer supported using this command in FORTRAN 4.x because of new
 functionality added to FORTRAN 4.x.


 137. How To Access the Comm Port or Printer

 Product Version(s): 4.X  5.0
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 31-OCT-1989    ArticleIdent: Q28134

    To access the comm port or printer, simply open the device in the
 following way:

        OPEN(UNIT=10,FILE='COM1',STATUS='OLD')

     or

        OPEN(UNIT=9,FILE='LPT1',STATUS='OLD')

    One may then write to or read from them as to any other unit.
 However, they must be treated as sequential files (which is the
 default). See page 105 of the FORTRAN 4.X Language reference or
 page 63 of the FORTRAN 5.0 Reference for a description of sequential
 file access.


 138. CHARACTER Array Optimization

 Product Version(s): 4.00a
 Operating System:   MS-DOS
 Flags: ENDUSER | ptr900141 bcp1758 buglist4.00 fixlist4.01
 Last Modified:  1-JUN-1988    ArticleIdent: Q23342

    The following program:

            character*30 strs(10),temp
            strs(1) = 'name1'
            strs(2) = 'name2'
            strs(3) = 'name3'
            strs(4) = 'name4'
            strs(5) = 'name5'
            do 10 i =1,5
            write (*,*) 'name is '//strs(i)
    10      continue
            end

 should produce the following output:

    name is name1
    name is name2
    name is name3
    name is name4
    name is name5

 however, it actually prints the following:

    name is name5name4name3name2name1+ &
    name is name5name4name3name2name1+ &
    name is name5name4name3name2name1+ &
    name is name5name4name3name2name1+ &
    name is name5name4name3name2name1+ &

    This problem was corrected in Version 4.01.

    This problem can be worked around either by compiling with option
 -Odclt or by setting a CHARACTER variable equal to the CHARACTER
 expression and using the variable (rather than the expression) in the
 WRITE statement.


 139. Spurious F2408 Errors

 Product Version(s): 4.00a
 Operating System:   MS-DOS
 Flags: ENDUSER | ptr900142 bcp1748 buglist4.00
 Last Modified:  1-JUN-1988    ArticleIdent: Q23343

    The following program:

         INTEGER x(10), y(10)
         DATA x(1:10) /1/
         DATA y/10*0/
         END

 should produce the following errors when compiled:

    error F2513: X : not a variable
    error F2537: X : array subscripts missing

    however, it actually prints the following:

     error F2513: X : not a variable
     error F2537: X : array subscripts missing
     error F2408: X : DATA : too few constants to initialize item
     error F2408: Y : DATA : too few constants to initialize item

    This problem was corrected in Version 4.01.
    The F2408 errors were occurring as a result of two previous errors.
 This is called a "cascade" error.


 140. Code Generation Error

 Product Version(s): 4.00a
 Operating System:   MS-DOS
 Flags: ENDUSER | ptr900136 bcp1745 buglist4.00 fixlist4.01
 Last Modified:  1-JUN-1988    ArticleIdent: Q23344

    The following program:

         complex xx(4)
         common /elem/p(75,8)
         a = p(j,5)+1.
         b = w*p(j,4)*p(j,3)*1.e-12
         xx(2) = p(j,3)/cmplx(a,b)
         end

 generates the following compilation error:

    a:0056.for(5) : error F2124: CODE GENERATION ERROR
                    Contact Microsoft Technical Support

    This problem was corrected in Version 4.01.
    You can work around this problem by compiling with either the -Od
 or the -Odl option.


 141. Compiler Hung by Real Subscript

 Product Version(s): 4.00a
 Operating System:   MS-DOS
 Flags: ENDUSER | ptr900128 bcp1706 buglist4.00 fixlist4.01
 Last Modified:  1-JUN-1988    ArticleIdent: Q23345

    The following program will cause the compiler to hang:

         dimension int(100)
         common pjint(100)
         x = 1.0
         pjint(x) = int(min0(x,21))
         end

    This problem was corrected in Version 4.01.
    This program relies on two features that are not part of the ANSI
 X3.9-1978 FORTRAN standard: the use of a REAL variable as an array
 index, and the use of a REAL variable as an argument to an intrinsic
 function that is expecting only INTEGER arguments. If the $STRICT
 metacommand or -4Ys switch had been used, both uses would have been
 flagged as errors. Nevertheless, the program should not hang the
 compiler.
    The following is a workaround:

    1. Calculate the subscript expression for the array INT.
    2. Store it in a temporary integer variable.
    3. Use the temporary variable to index the array.


 142. Error F2350

 Product Version(s): 4.00a
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 20-OCT-1988    ArticleIdent: Q23346

 Problem:

 Consider the following program:

        program foo
        call main
        end

        subroutine main
        end

 The Version 4.00 compiler generates error message "F2530: MAIN :
 symbol class illegal here". The Version 3.31 compiler compiles this
 without error. Is this error message consistent with the standard?

 Response:

 This is consistent with the ANSI X3.9-1978 FORTRAN standard (see Page
 14-1). Remember that the entry point "_main" is always defined for the
 main program. The language reference manual discusses this in detail
 in Section 3.8 on Page 62, explaining where "main" can and cannot be
 used.


 143. Premature EOF on Redirected READs

 Product Version(s): 4.00a
 Operating System:   MS-DOS
 Flags: ENDUSER | ptr900103 bcp1686 buglist4.00 fixlist4.01
 Last Modified: 16-JUN-1988    ArticleIdent: Q23349

    If the following program is run with the READ redirected from the
 console to a file that contains one or more CTRL-Zs at the end, you
 may receive a premature (or perhaps an immediate) end-of-file message:

          CHARACTER CHR
    10    CONTINUE
          READ(*,'(A)') CHR
          WRITE(*,'(1X,A)') CHR
          GOTO 10
          END

    The behavior may differ, depending on the length of the redirected
 file. The problem is occurring because the run time is detecting
 end-of-file when a BUFFER is read that contains a CTRL-Z, rather than
 when the CTRL-Z itself is read.
    This problem was corrected in Version 4.01.


 144. Internal READ from Substring

 Product Version(s): 4.00a
 Operating System:   MS-DOS
 Flags: ENDUSER | ptr900104 bcp1689 buglist4.00
 Last Modified: 20-OCT-1988    ArticleIdent: Q23350

 Problem:

 The following program

        character str*10
        str = '1234567890'
        call sub1 (str)
        end
        subroutine sub1(str)
        character str*(*)
        read (str(2:6),'(i5)') inum
        write (*,*) 'inum should be 23456, is=<',inum,'>'
        end

 should produce the following output:

 inum should be 23456, is=<      23456>

 However, it actually prints the following:

 inum should be 23456, is=<          0>

 Response:

 Microsoft has confirmed this to be a problem in Version 4.00. This
 problem was corrected in Version 4.01.

 This problem is caused by an internal WRITE to a substring of a
 CHARACTER*(*) parameter. The problem can be worked around in the
 following two ways:

 1. In the subroutine, declare STR to be of a fixed size instead of
    CHARACTER*(*).

 2. In the internal READ, use STR instead of the substring of STR.

 This was provided as an extra case for the developers.


 145. Internal Compiler Error: pgo2.c, Line 229

 Product Version(s): 4.00A
 Operating System:   MS-DOS
 Flags: ENDUSER | ptr900095 bcp1672 buglist4.00a fixlist4.01
 Last Modified:  1-JUN-1988    ArticleIdent: Q23351

 Problem:
    A program containing several ENTRY points, most of which have
 alternate return arguments, is giving the assertion error "Pgo2.c,
 line 229" with only the default compiler switches.

 Response:
    This is a known problem in Version 4.00a.
    This problem was corrected in Version 4.01.
    The program has been reduced from 1100+ to 423 lines. The assertion
 seems to occur only in conjunction with the "function too big for
 post-optimizer" message, so most likely that will occur only when
 memory size is limited (the test was run with 416K available).


 146. "Symbol Undefined" and Length of FORTRAN Variable Name

 Product Version(s): 4.X
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 19-APR-1988    ArticleIdent: Q23352

 Problem:
    I am debugging a FORTRAN program and am finding that I
 cannot view any symbols with a name longer than six
 characters. For instance, using "? longvarname" produces
 the message "Symbol undefined" in CodeView.

 Response:
    Under Microsoft FORTRAN Version 4.0, only the first six
 characters of a symbol name are recognized by default. If
 you want the full name to be valid, you must use the
 $NOTRUNCATE metacommand or compile with the /4Nt switch.
 Without the metacommand or the switch, CodeView considers
 the symbol "longvarname" to be "longva". This is why you
 could not display the expression. (Had you entered
 "?longva", CodeView would have displayed the symbol
 correctly.)


 147. Internal Compiler Error: regMD.c 1.74, Line 1495

 Product Version(s): 4.00A
 Operating System:   MS-DOS
 Flags: ENDUSER | ptr900158 bcp1788 buglist4.00 fixlist4.01
 Last Modified:  1-JUN-1988    ArticleIdent: Q23356

 Problem:
    The following program:

       COMMON/SIG/R(100,24)
       REAL*8    R,RA1(24)
       DO 4301 K=1,24
  4301 RA1(K)= R(KA, K)
  4310 K=K+KO
       IF(K .NE. KZ) GOTO 4310
       RAD = R(KR,2)
       END

 produces the following error when compiled with the default options:

 bcp1788.for(7) : fatal error F1001: Internal Compiler Error
                 (compiler file '@(#)regMD.c:1.74', line 1495)
                 Contact Microsoft Technical Support

 Response:
    This is a known problem in Version 4.00.
    This problem was corrected in Version 4.01.
    You can correct the problem by compiling with the -Odclt
 switch. The array must be in COMMON for the error to
 occur.


 148. READ from Internal File Substring

 Product Version(s): 4.00a
 Operating System:   MS-DOS
 Flags: ENDUSER | ptr900143 bcp1760 buglist4.00 fixlist4.01
 Last Modified:  1-JUN-1988    ArticleIdent: Q23360

    The following program:

    $debug
            character*20 strc
            data itmp1,itmp2,strc /5,3,'1234567890'/
            read (strc(itmp1:itmp1+itmp2),'(f20.0)') temp
            write (*,*) 'temp should be 5678.0 and is=',temp
            end

 should produce the following output:

    temp should be 5678.0 and is=    5678.000000

 however, it actually prints the following:

    temp should be 5678.0 and is=   0.000000E+00

    This problem was corrected in Version 4.01.
    Two workarounds are as follows:

    1. Compile without $DEBUG.
    2. Store the integer expression in a variable and use it in the
 substring.


 149. FORTRAN Version 4.10 DOS, OS/2 Requirements

 Product Version(s): 4.10   | 4.10
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | docerr
 Last Modified:  7-SEP-1988    ArticleIdent: Q28335

 Question:

 Page 1 of the Update (Update-1), of the FORTRAN Version 4.10 insert
 for "Microsoft FORTRAN Optimizing Compiler User's Guide" states that
 DOS Version 3.00 (or later) is required. However, the product box
 states that DOS Version 2.10 (or later) is required. Which is correct?

 Response:

 The product box is correct. The Update should state that Microsoft
 FORTRAN Version 4.10 requires DOS Version 2.10 (or later).


 150. Block Data Names in Listing

 Product Version(s): 4.00a
 Operating System:   MS-DOS
 Flags: ENDUSER | ptr900155 bcp1780 buglist4.00
 Last Modified:  1-JUN-1988    ArticleIdent: Q23373

    Garbled characters are appearing in a list file where, normally,
 the name of the routine is printed.

    There is no workaround for this problem. The following program
 reproduces the problem:

   Line#  Source Line   Microsoft FORTRAN Optimizing Compiler Version 4.00

       1        block data
       2        common /any/x(5)
       3        data x/1.,2.,3.,4.,5./
       4        end
       5        block data foo
       6        common /bar/ a
       7        data a /.5/
       8        end

 [garbage]  Local Symbols

 Name                      Class   Type              Size   Offset

 X . . . . . . . . . . . . ANY     REAL*4              20    0000
 A . . . . . . . . . . . . BAR     REAL*4               4    0000

 Global Symbols

 Name                      Class   Type              Size   Offset

 ANY . . . . . . . . . . . common  CHAR*20             20    0000
 BAR . . . . . . . . . . . common  CHAR*4               4    0000

 Code size = 0000 (0)
 Data size = 0000 (0)
 Bss size  = 0000 (0)

 No errors detected


 151. Internal Compiler Error: regMD.c 1.74, Line 285

 Product Version(s): 4.00A
 Operating System:   MS-DOS
 Flags: ENDUSER | ptr900159 bcp1794 buglist4.00 fixlist4.01
 Last Modified:  1-JUN-1988    ArticleIdent: Q23364

 Problem:
    The following program:

         character*1 dirinfo(30,10)
         integer*4 filesize
         filesize = ichar(dirinfo(29,i))*65536 +
      +             ichar(dirinfo(28,i))*256+
      +             ichar(dirinfo(27,i))
         end

 produces the following compilation error if compiled with option -4I2:

    fatal error F1001: Internal Compiler Error
    (compiler file '@(#)regMD.c:1.74', line 285)
      Contact Microsoft Technical Support

 Response:
    This is a known problem in Version 4.00.
    This problem was corrected in Version 4.01.
    Aside from the fact that this program will cause an assertion
 error, it will, even after the assertion error is corrected, produce
 an incorrect answer. The right-hand side of the expression is being
 evaluated in INTEGER*2 arithmetic; the conversion to the type of the
 destination variable (INTEGER*4) is done only after the evaluation is
 complete. Were this program able to run, it would produce a runtime
 error F6099 : "INTEGER overflow" if compiled with both -4I2 and -4Yb
 options. There are two ways to work around the problem, as follows:

    1. Do not compile with the -4I2 option.
    2. Assign the three ICHAR expressions to temporary INTEGER*4
 variables and use them to calculate FILESIZE.


 152. Edit Descriptor File Clash

 Product Version(s): 4.00a
 Operating System:   MS-DOS
 Flags: ENDUSER | ptr900102 bcp1684 buglist4.00
 Last Modified:  1-JUN-1988    ArticleIdent: Q23348

    The following program:

       REAL*8 D1,D2,GV
       INTEGER K1
       CHARACTER*4 IDNO(2),IDNM(4)
       OPEN(11,FILE='bcp1684a.DAT',STATUS='OLD')
       DO 1 J=1,100
       READ(11,1000,END=15) IDNO,D1,D2,GV,IDNM,K1
       WRITE(*,1000) IDNO,D1,D2,GV,IDNM,K1
     1 CONTINUE
    15   continue
         close(11)
         open(12,file='bcp1684b.dat')
       DO 2 J=1,100
       READ(12,1000,END=25,IOSTAT=IOCHCK) IDNO,D1,D2,GV,IDNM,K1
       IF(IOCHCK.NE.0) WRITE(*,1001)IOCHCK
       WRITE(*,1000) IDNO,D1,D2,GV,IDNM,K1
     2 CONTINUE
  1000 FORMAT(2X,A4,A3,11X,2F10.5,1X,F9.2,4A4,I4)
  1001 FORMAT(2X,'***IOSTAT= ',I7)
    25 STOP
       END

 should produce the following output:

   926860             49.35067-124.44583 980979.89QUALICUM           1
   940575             50.03217-125.26867 981060.64CAMPBELL RIVER     2
   940675             49.77883-126.04967 980992.53GOLD RIVER         3
   903177             49.82083-125.60000 980966.15LUPIN MOUNTAIN     4
   903277             49.88167-125.69500 980989.57FILBERG CREEK      5
   903377             49.92683-125.64300 980994.35CEDAR CREEK        6
   903477             49.73750-125.56417 980937.37MOUNT ADRIAN       7
   903577             49.85417-125.81117 980967.48ELK RIVER          8
   903677             49.96133-125.53333 980970.64GOOSENECK LAKE     9
   903777             49.67250-125.53917 980930.34PHILLIPS CREEK    10
   903877             49.84150-125.91533 980961.07CREST CREEK       11
   903977             49.98667-125.40450 981012.61ECHO LAKE         12
   904077             49.57667-125.56383 980918.94MYRA FALLS        13
   904177             49.74633-126.07050 980999.32GOLD RIVER        14
   904277             50.02167-125.36667 981030.99MCIVOR LAKE       15
   904377             49.31333-124.55333 980972.06LITTLE QUALICUM   16
   904477             49.26000-124.70833 980930.52ARROWSMITH MTN    17
   904577             49.27167-124.87167 981003.25TSAHAHEH          18
   904677             49.28500-125.02667 980980.77SPROAT LAKE       19
   904777             49.28833-125.19667 980970.51TAYLOR ARM        20
   926860             49.35067-124.44583 980979.89QUALICUM           1
   940575             50.03217-125.26867 981060.64CAMPBELL RIVER     2
   940675             49.77883-126.04967 980992.53GOLD RIVER         3
   903177             49.82083-125.60000 980966.15LUPIN MOUNTAIN     4
   903277             49.88167-125.69500 980989.57FILBERG CREEK      5
   903377             49.92683-125.64300 980994.35CEDAR CREEK        6
   903477             49.73750-125.56417 980937.37MOUNT ADRIAN       7
   903577             49.85417-125.81117 980967.48ELK RIVER          8
   903677             49.96133-125.53333 980970.64GOOSENECK LAKE     9
   903777             49.67250-125.53917 980930.34PHILLIPS CREEK    10
   903877             49.84150-125.91533 980961.07CREST CREEK       11
   903977             49.98667-125.40450 981012.61ECHO LAKE         12
   904077             49.57667-125.56383 980918.94MYRA FALLS        13
   904177             49.74633-126.07050 980999.32GOLD RIVER        14
   904277             50.02167-125.36667 981030.99MCIVOR LAKE       15
   904377             49.31333-124.55333 980972.06LITTLE QUALICUM   16
   904477             49.26000-124.70833 980930.52ARROWSMITH MTN    17
   904577             49.27167-124.87167 981003.25TSAHAHEH          18
   904677             49.28500-125.02667 980980.77SPROAT LAKE       19
   904777             49.28833-125.19667 980970.51TAYLOR ARM        20
 Stop - Program terminated.

 however, it actually prints the following:

   926860             49.35067-124.44583 980979.89QUALICUM           1
   940575             50.03217-125.26867 981060.64CAMPBELL RIVER     2
   940675             49.77883-126.04967 980992.53GOLD RIVER         3
   903177             49.82083-125.60000 980966.15LUPIN MOUNTAIN     4
   903277             49.88167-125.69500 980989.57FILBERG CREEK      5
   903377             49.92683-125.64300 980994.35CEDAR CREEK        6
   903477             49.73750-125.56417 980937.37MOUNT ADRIAN       7
   903577             49.85417-125.81117 980967.48ELK RIVER          8
   903677             49.96133-125.53333 980970.64GOOSENECK LAKE     9
   903777             49.67250-125.53917 980930.34PHILLIPS CREEK    10
   903877             49.84150-125.91533 980961.07CREST CREEK       11
   903977             49.98667-125.40450 981012.61ECHO LAKE         12
   904077             49.57667-125.56383 980918.94MYRA FALLS        13
   904177             49.74633-126.07050 980999.32GOLD RIVER        14
   904277             50.02167-125.36667 981030.99MCIVOR LAKE       15
   904377             49.31333-124.55333 980972.06LITTLE QUALICUM   16
   904477             49.26000-124.70833 980930.52ARROWSMITH MTN    17
   904577             49.27167-124.87167 981003.25TSAHAHEH          18
   904677             49.28500-125.02667 980980.77SPROAT LAKE       19
   904777             49.28833-125.19667 980970.51TAYLOR ARM        20
  ***IOSTAT=    6103
  26860                4.93507  24.44584 980970.51TAYLOR ARM        20
  ICUM                  .00000    .00000       .00                   0
   940575             50.03217-125.26867 981060.64CAMPBELL RIVER     2
   940675             49.77883-126.04967 980992.53GOLD RIVER         3
   903177             49.82083-125.60000 980966.15LUPIN MOUNTAIN     4
   903277             49.88167-125.69500 980989.57FILBERG CREEK      5
   903377             49.92683-125.64300 980994.35CEDAR CREEK        6
   903477             49.73750-125.56417 980937.37MOUNT ADRIAN       7
   903577             49.85417-125.81117 980967.48ELK RIVER          8
   903677             49.96133-125.53333 980970.64GOOSENECK LAKE     9
   903777             49.67250-125.53917 980930.34PHILLIPS CREEK    10
   903877             49.84150-125.91533 980961.07CREST CREEK       11
   903977             49.98667-125.40450 981012.61ECHO LAKE         12
   904077             49.57667-125.56383 980918.94MYRA FALLS        13
   904177             49.74633-126.07050 980999.32GOLD RIVER        14
   904277             50.02167-125.36667 981030.99MCIVOR LAKE       15
   904377             49.31333-124.55333 980972.06LITTLE QUALICUM   16
   904477             49.26000-124.70833 980930.52ARROWSMITH MTN    17
   904577             49.27167-124.87167 981003.25TSAHAHEH          18
   904677             49.28500-125.02667 980980.77SPROAT LAKE       19
   904777             49.28833-125.19667 980970.51TAYLOR ARM        20
 Stop - Program terminated.

    By the time the EOF is encountered on the first file, the run time
 has already "seen" a 2X edit descriptor. The 2X edit descriptor by
 itself does nothing until a repeatable edit descriptor is seen; it is
 merely "remembered". Unfortunately, it remembers even after the close
 of the file.
    This situation should arise only when EOF is encountered at the
 same time when a non-repeatable edit descriptor has been READ without
 having been followed by a repeatable. You can solve this problem by
 replacing the 2X descriptor with an I2 that READs into a dummy
 variable.


 153. Internal Compiler Error: regMD.c 1.79, Line 608

 Product Version(s): 4.01 4.10 | 4.10
 Operating System:   MS-DOS    | OS/2
 Flags: ENDUSER | buglist4.01 buglist4.10 fixlist5.00
 Last Modified:  6-NOV-1989    ArticleIdent: Q28340

 The code sample below will generate the following internal compiler
 error:

    REGMD.FOR
    REGMD.FOR(6) : fatal error F1001: Internal Compiler Error
                    (compiler file '@(#)regMD.c:1.79', line 608)
                    Contact Microsoft Technical Support

 Microsoft has confirmed this to be a problem in Versions 4.01 and
 4.10 of the FORTRAN compiler. This problem was corrected in Version
 5.00.

 You can work around the error by breaking up line six with a temporary
 variable, as in the following code:

       SUBROUTINE FOO
       IMPLICIT INTEGER*2 (A-Z)
       INTEGER*4 LA
       INTEGER*2 PUROUT,MAX,LOST

       TMP = MAX*PUROUT*3
       LA = LOST+TMP
       RETURN
       END

 The following is the code:

       SUBROUTINE FOO
       IMPLICIT INTEGER*2 (A-Z)
       INTEGER*4 LA
       INTEGER*2 PUROUT,MAX,LOST

       LA = LOST+MAX*PUROUT*3
       RETURN
       END


 154. Incorrect Error F2352

 Product Version(s): 4.00a
 Operating System:   MS-DOS
 Flags: ENDUSER | ptr900157 bcp1786
 Last Modified: 20-OCT-1988    ArticleIdent: Q23412

 Question:

 Why does the following program produce the following compilation
 errors?

        common /xx/ w(10)
        common y(5)
        foo(y,w) = y*w
        end

        error F2352: Y : formal argument not local variable
        error F2352: W : formal argument not local variable

 Response:

 This behavior is a correct response; the program is syntactically
 incorrect. According to the ANSI X3.9-1978 FORTRAN standard, you can
 reuse the statement function's dummy arguments as variable names and
 COMMON block names in the same program, but you cannot use them as
 array names (ANSI X3.9-1978 FORTRAN standard, Page 15-4, lines 39-44).


 155. Internal Compiler Error: sortnode.c, Line 154

 Product Version(s): 4.00a
 Operating System:   MS-DOS
 Flags: ENDUSER | ptr900109 bcp1697 buglist4.00
 Last Modified:  1-JUN-1988    ArticleIdent: Q23450

    The program below gives the assertion error message "sortnode.c,
 line 154":

         CHARACTER A,B,C,D,E,F,G
         CHARACTER BIGLIN*60, LSTHAF*30
         A = 'A'
         B = 'B'
         C = 'C'
         D = 'D'
         E = 'E'
         F = 'F'
         G = 'G'
         LSTHAF = '123456789012345678901234567890'
         BIGLIN = ' '//A//'   '//B//'   '//C//
      +           '   '//D//'   '//E//'   '//F//'   '//
      +           G//LSTHAF
         WRITE (*,*) 'BIGLIN=<',BIGLIN,'>'
         END

    The workaround for this problem is breaking up the character
 expression into smaller pieces.


 156. Null Pointer Assignment Error in PAS2.EXE

 Product Version(s): 3.31
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist3.31
 Last Modified:  7-NOV-1988    ArticleIdent: Q23483

 Problem:

 PAS2.EXE of the compiler seems to run properly, but when it finishes
 it prints out the error message "Null Pointer Assignment."

 Response:

 This behavior indicates that there was an error during the
 execution of PAS2.EXE.

 Microsoft has confirmed this to be a problem related to the size of
 the compiler's stack in Version 3.31. We are researching this problem
 and will post new information as it becomes available.

 You should reduce the stack sizes of both FOR1.EXE and PAS2.EXE
 from 40K down to 20K using the EXEMOD.EXE utility (which is included
 with the compiler), using the following lines:

    exemod for1 /stack 5000
    exemod pas2 /stack 5000

 For more information about the EXEMOD.EXE utility, refer to the user's
 guide, Appendix A.10.1, Page 159.


 157. Use and Misuse of Format(X,\)

 Product Version(s): 4.00A
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified:  4-MAY-1988    ArticleIdent: Q23434

 Question:
    I am trying to use the "\" after an "X" in a FORMAT statement. I
 tried the following using the current Version 4.00:

    write(*,10)
    10  format(1x,'Enter a number :',10x,\)

    The 10x still is being ignored in Version 4.00. Are there any plans
 to change this, or will this be a feature?

 Response:
    It is assumed by some that the X edit descriptor produces some
 output. However, it does not. It positions a pointer that says where
 the next character is to be (in this case) written.
    For more information on this, please see lines 4-10 on Page 13-6 of
 the "ANSI X3.9-1978 FORTRAN standard document."
    Because nothing further actually is written on this line, the
 current behavior is correct.
    If you wish to hang the cursor following the prompt, you can do so
 by inserting the required number of blanks as the last item in the
 prompt; within the CHARACTER constant.


 158. Scratch File on Units 5 and 6

 Product Version(s): 4.00a
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 30-JAN-1989    ArticleIdent: Q23443

 Question:

 I am having trouble with the following program:

 program t
 open(5,status='scratch')
 write(5,*) 'help'
 end

 This program writes "help" to the screen. Is this correct
 behavior?

 Response:

 Version 4.00 does not allow any of the pre-connected units (0, 5, and
 6) to be used as scratch files. Because there are 65531 other unit
 numbers that could be used as scratch file units, this should not be
 an inconvenience.


 159. F6301 Error and Opening Scratch Files with Names

 Product Version(s): 4.00 4.01 4.10 5.00 | 4.10 5.00
 Operating System:   MS-DOS              | OS/2
 Flags: ENDUSER | docerr FORTRAN 77
 Last Modified: 26-JUL-1990    ArticleIdent: Q23465

 Page 253 of the "Microsoft FORTRAN Optimizing Compiler Language
 Reference" for versions 4.00, 4.01, and 4.10 and Page 206 of the
 "Microsoft FORTRAN Reference" for version 5.00 contain a documentation
 error that states a named file may be opened with STATUS='SCRATCH'.

 This is contrary to Page 12-19, lines 18 and 19, of the "American
 National Standard (ANSI) Programming Language FORTRAN" guide, which
 state "SCRATCH must not be specified with a named file."

 The compiler correctly generates the following run-time error:

    F6301 : SCRATCH illegal for named file

 The following OPEN statement generates the run-time error "F6301:
 SCRATCH illegal for named file":

    OPEN(6,FILE='JUNK',STATUS='SCRATCH')

 The "American National Standard (ANSI) Programming Language FORTRAN"
 guide states that "SCRATCH must not be specified with a named file."
 It may seem redundant to have a STATUS "SCRATCH" when the following
 two statements perform the same function:

    OPEN (1)
    OPEN (1,STATUS='SCRATCH')

 However, specifying"SCRATCH" for a named file provides documentation
 that the file will be deleted when the program finishes.


 160. BACKSPACE Versus Blocksize

 Product Version(s): 4.00A
 Operating System:   MS-DOS
 Flags: ENDUSER | bcp1850 buglist4.00
 Last Modified: 26-MAY-1988    ArticleIdent: Q23538

 Problem:
    The following program:

         dimension x(3000),y(3000),z(3000)
         ibl = 32256
         open (1,file='temp.dat')
         do 100 i=1,3000
           x(i) = i+10000
 100     continue
         write (1,'(3000f6.0)') x
         do 200 i=1,3000
           x(i) = i+20000
 200     continue
         write (1,'(3000f6.0)') x
         close (1)
         open (1,file='temp.dat',blocksize=ibl)
         read (1,'(3000f6.0)') y
         backspace 1
         read (1,'(3000f6.0)') y
         read (1,'(3000f6.0)') z
         backspace 1
         read (1,'(3000f6.0)') z
         write (*,'(1x,a,10f7.0)') 'y=',(y(i),i=1,5),(y(i),i=2996,3000)
         write (*,'(1x,a,10f7.0)') 'z=',(z(i),i=1,5),(z(i),i=2996,3000)
         close (1,status='delete')
         end

 should produce the following output:

 y= 10001. 10002. 10003. 10004. 10005. 12996. 12997. 12998. 12999. 13000.
 z= 20001. 20002. 20003. 20004. 20005. 22996. 22997. 22998. 22999. 23000.

    However, it actually prints the following:

    run-time error F6501: BACKSPACE(temp.dat)
    - end of file encountered

 Response:
    This is a known problem in Version 4.00.
    There is an error in the run time that causes incorrect positioning
 when a BACKSPACE is performed on a file whose BLOCKSIZE is greater
 than 16384 bytes (e.g. 16896 to 32256 bytes). Since the problem will
 only occur when a BLOCKSIZE greater than 16384 is used, those programs
 that also use BACKSPACE should use a BLOCKSIZE of 512 to 16384 bytes.


 161. Subtracting a Complex*8 from a Real Constant

 Product Version(s): 4.00
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist4.00 fixlist4.01
 Last Modified: 26-MAY-1988    ArticleIdent: Q23581

 Problem:
    The following program should produce the output
 "(5.000000E-01,-5.000000E-01)"; however, the program instead produces
 the output "(5.000000E-01,5.000000E-01)":

    COMPLEX*8 A,B
       A=(0.5,0.5)
       B=1.0 - A
       WRITE(*,*)B

 Response:
    This is a known problem in Version 4.00.
    This problem was corrected in FORTRAN Version 4.01.
    If A and B are COMPLEX*16, the calculation is correct.


 162. Internal Compiler Error: regMD.c 1.74, Line 285

 Product Version(s): 4.00
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist4.00 fixlist4.01
 Last Modified:  1-JUN-1988    ArticleIdent: Q23587

 Problem:
    The following program gives the assertion error "regMD.c:1.74, line
 285" when it is compiled with both -FPa and -Od:

    SUBROUTINE VLNGET(XMIN,XMAX)
    DIMENSION XMIN(1),XMAX(1)
    NLI = NINT(XMAX(II)) - NINT(XMIN(II)) + 1
    END

 Response:
    This is a known problem in Version 4.00 of the FORTRAN compiler.
 The problem was corrected in Version 4.01.
    The workaround is to avoid the -FPa and -Od option combination.


 163. F2124 - Code Generation Error with Complex Numbers

 Product Version(s): 4.00
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist4.00 fixlist5.0
 Last Modified: 14-JUL-1989    ArticleIdent: Q23586

    The compiler generates error F2124, "code generation error" for the
 following code:

    COMPLEX A,B,C
    D=REAL(CONJG(C)*A*B)
    END

    This is a known problem in Version 4.00.
    If you add the complex variable temp and simplify the expression,
 as in the following example, then the error is corrected:

    temp=conjg(c)
    d=real(temp*a*b)

    This is similar to an earlier assertion error (mactab.c:1.30,
 line 647) caused by the following program:

    complex*16 z1,z2,z3
    z1=z1*dconjg(z2) *z3
    end

    This problem had basically the same workaround, but concerned only
 COMPLEX*16. Changing the optimization has no effect.


 164. Internal Compiler Error: regMD.c 1.74, Line 1267

 Product Version(s): 4.00
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist4.00
 Last Modified: 26-MAY-1988    ArticleIdent: Q23588

 Problem:
    The following code generates the regMD.c:1.74, line 1267 error
 message:

    SUBROUTINE BIAS(IAE)
    CHARACTER*1 BUF6(512)
    DIMENSION IBIAS(64,2)
    BUF6(1) = CHAR(IBIAS(L,IAE))
    END

 Response:
    This is a known problem in Version 4.00.
    If you assign IAE to a local variable, the error is corrected.
    The pattern here seems to be a two-dimensional array reference
 inside a function (a one-dimensional pattern will not work), where one
 of the array dimensions is a local variable and the other is an
 argument.


 165. Compile Time Error F2215

 Product Version(s): 4.00
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist4.00 fixlist4.01
 Last Modified: 26-MAY-1988    ArticleIdent: Q23582

 Problem:
    The following program generates an incorrect F2215 error
 ("character lengths differ"):

         SUBROUTINE PAGE
         IMPLICIT CHARACTER*1 (A-H,J-Z)
         ENTRY PAGOUT
         END

 Response:
    Microsoft confirmed this to be a problem in Version 4.00 of the
 FORTRAN compiler. The problem was corrected in Version 4.01.
    FORTRAN Version 4.00 issues an error that is only appropriate for a
 function since subroutines have no associated type.
    The workaround is to avoid using the IMPLICIT CHARACTER statement,
 using explicit type statements instead.


 166. Problem with Expressions as Arguments to WRITE

 Product Version(s): 4.00
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist4.00 fixlist4.01
 Last Modified:  1-JUN-1988    ArticleIdent: Q23584

    The following program will produce a code generation error:

            real bs(3,3),br(3,3),ps(3,3),psp(3),bsp(3),bso(3),rp(3),ro(3)
               WRITE(6,350)
         +  aguse(I,J)/customers(J),
         x  agg(bs(I,J),1.0)+AGG(BR(I,J),1.0),
         +  AGG(BR(I,J)-PS(I,J),1.0),
         X  AGG(BS(I,J)+BR(I,J)-PS(I,J),1.0)
    350    FORMAT(3(1X,A22,F9.1,7F8.2,3X,F8.2))
            end

    Microsoft confirmed this to be a problem in Version 4.00 of the
 FORTRAN compiler. The problem was corrected in Version 4.01.
    The workaround is to store the expressions in temporary variables
 and WRITE those temporary variables.


 167. Loop Optimization Problems

 Product Version(s): 4.00
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist4.00 fixlist4.01
 Last Modified:  1-JUN-1988    ArticleIdent: Q23585

    If the following code is compiled with /Odclt or the default, the
 program does not work properly:

    $STORAGE:2
           DO 100 I=1,2
           J=0
    50     J=J+1
           IF(J .GT. 2) GOTO 100
           WRITE(*,*) 'I,J=',I,J
           GOTO 50
    100    CONTINUE
           END

    Microsoft confirmed this to be a problem in Version 4.00 of the
 FORTRAN compiler. This problem was corrected in Version 4.01.
    If you remove $STORAGE:2, if you compile with /Od (disables
 optimization), or /Odct, the correct code is generated.


 168. Error F2317 - Using Equivalence

 Product Version(s): 4.00
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist4.00
 Last Modified:  1-JUN-1988    ArticleIdent: Q23583

    Placing real numbers in a common block with an array of CHARACTER*1
 generates the message "error F2317" and the following example code:

    REAL*8 EMPEPR, EMPSPR
    CHARACTER*1 EMPBUF(2091)
    COMMON /TEST/ EMPEPR, EMPSPR
    EQUIVALENCE(EMPEPR,EMPBUF(2:9))
    EQUIVALENCE(EMPSPR,EMPBUF(10:17))

    There are two problems in the code. They are as follows:

    1. Because EMPBUF is a CHARACTER*1 array, you cannot expect
 anything substantial when attempting to extract any substring (except,
 of course, (1:1)) from a single character variable or array element.
 In this case, the compiler apparently ignores the substring reference.
 This means that both variables in the common block are EQUIVALENCEd to
 the same location, EMPBUF(1). The solution is to change the type of
 EMPBUF to CHARACTER*2091.
    2. The other problem arises if the first is solved. The compiler
 must align numeric variables on even-byte boundaries and the
 EQUIVALENCE attempts to force it to an odd location. Changing EMPBUF
 to CHARACTER*2091 and the substrings to (1:8) and (9:16) allows the
 program to compile without error.


 169. Internal Compiler Error: p2symtab.c 1.84, Line 918

 Product Version(s): 4.00
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist4.00 fixlist4.01
 Last Modified: 16-JUN-1988    ArticleIdent: Q23636

    The following program generates the assertion error
 "p2symtab.c:1.84, line 918":

      program basmap
      character*16 basmap(3)
      data basmap/ '\EXCLAND.pix\   ','\INCLAND.pix\    ',
    1  '\WATLAND.pix\   '/
      call gwrite(basmap(mask))

    The compiler is not producing an error when the program name is
 used as an array. This is a violation of the standard; "basmap" cannot
 be a name of a subroutine, function, or COMMON block in the same
 source file. Furthermore, it cannot be the same as any local name in
 the main program (see Ref. ANSI X3.9-1978, Page 14-1).
    The workaround is to change the program name or to delete the
 program statement.


 170. Running Out of Heap Size

 Product Version(s): 3.31
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified:  9-MAR-1988    ArticleIdent: Q23691

 Problem:
    FORTRAN Version 3.31 is generating the error "? error :
 out of memory" at compile time.

 Response:
    Version 3.31's compiler stack size has increased to 40K,
 which is too large. The compiler is running out of heap
 size. For Version 3.31, the following will get around this
 problem:

    1. Decrease the size of the compiler stack for F1.EXE to
 20K or 30K using EXEMOD.
    2. The program may be too large; break it down into
 several modules.


 171. Determining Size of Code and Data

 Product Version(s): 4.00
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified:  3-DEC-1987    ArticleIdent: Q23683

 Question:
    How do I determine the size of the code and data
 segments in each module?

 Response:
    If you specify the /Fs option to generate a listing
 (.LST file), the sizes of the code and data appear at the
 bottom.


 172. Namelist Support in FORTRAN

 Product Version(s): 3.x 4.00 4.01 4.10 5.00
 Operating System:   MS-DOS | 4.10 5.00
 Flags: ENDUSER |
 Last Modified: 18-OCT-1989    ArticleIdent: Q23696

 Question:
    Does FORTRAN Version 4.10 (and prior versions) support namelist?

 Response:
    No; namelist is an I/O statement that is an extension beyond the
 FORTRAN-77 Standard.

 Note: NAMELIST support was added with FORTRAN 5.0.


 173. How to Get Date and Time from FORTRAN

 Product Version(s): 3.20 3.30 3.31 4.00 4.01 4.10 | 4.10
 Operating System:   MS-DOS  | OS/2
 Flags: ENDUSER |
 Last Modified:  6-JAN-1989    ArticleIdent: Q23682

 Problem:
    What do I need to do in order to get FORTRAN to tell me
 the system date and time?

 Response:
    In Version 4.00, you may use the procedures GETTIM and
 GETDAT to get the time and the date, respectively. In
 FORTRAN Versions 3.3 and 3.2, use DATTIM.FOR as an example
 of how to get the date and time via a Pascal interface.


 174. Unresolved External __FHceadds in FORTRAN 4.10

 Product Version(s): 4.10   | 4.10
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | buglist4.10 fixlist5.00
 Last Modified: 25-FEB-1991    ArticleIdent: Q28436

 When I compile with the /Od option and link the following program with
 FORTRAN Version 4.10, I get the following error:

     Link : error 2029: Unresolved externals:  __FHceadds

 The program is as follows:

        DIMENSION D(8192)
        COMPLEX Y
 120    D(NMX-N)=(RN/Y)-(1./(D(NMX-N+1)+RN/Y))
        END

 The program will run, but it stops with a Floating Point Error.

 Response:

 The main problem is the mixed data types in the expression. If the
 COMPLEX variable Y is explicitly converted to REAL using the FLOAT
 type conversion intrinsic function then the program compiles and
 links.

 Another aspect of this problem is the size of the array. If it is small
 enough (less than 32K) to stay in dgroup, then it compiles properly.

 A less useful workaround is to compile with /Odclt, or to decrease
 the size of the array. If you are trying to use CodeView, compile with the
 switches /Zi /Odclt.

 Microsoft has confirmed this to be a problem in Version 4.10 of the
 FORTRAN compiler. This problem was corrected in Version 5.00.


 175. Creating One Megabyte of Code and Data

 Product Version(s): 3.20 3.30 3.31 4.00
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 20-APR-1988    ArticleIdent: Q23694

 Question:
    The product specifications state that I can create one megabyte of
 code and data. How can I accomplish this?

 Response:
    Because DOS limits the size of code and data segments to a maximum
 of 640K, you must use the Overlay Linker to overlay code. It would
 also save memory to read data from files rather than to store it all
 in RAM.


 176. Internal Compiler Error: ctypes.c 1.80, Line 1594

 Product Version(s): 4.00
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist4.00 fixlist4.01
 Last Modified:  1-JUN-1988    ArticleIdent: Q23638

 Problem:
    An internal compiler error "compiler file '@(#)ctypes.c:1.80', line
 1594" is generated by the following file:

 $debug
         subroutine test
         character*20    c
         i =1
         j=ichar(c(i:i))
         return
         end

    However, if you remove $debug, the program compiles without errors.

 Response:
    This is a known problem in Version 4.00 of the FORTRAN compiler.
 The problem was corrected in Version 4.01.


 177. Internal Compiler Error: regMD.c 1.74, Line 1267

 Product Version(s): 4.00
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist4.00
 Last Modified:  1-JUN-1988    ArticleIdent: Q23632

 Problem:
    The following code produces the regMD.c:1.74, line 1267 error:

    CHARACTER MATRIX(256,1)
    MATRIX(I,J) = ' '
    END

 Response:
    This is a known problem in Version 4.00.
    This is an extremely specific problem. The following conditions all
 must be true for failure:

    1. It must be a Character array.
    2. It must be two-dimensional (more than two dimensions were not
 examined).
    3. The first dimension must be exactly 256.

    This example does seem different than the previous code which
 produced this assertion: in this case, both dimensions are local vars.
 The previous code, in which the array reference consisted of a local
 var and a parameter, was as follows:

    SUBROUTINE BIAS(IAE)
    CHARACTER*1 BUF6(512)
    DIMENSION IBIAS(64,2)
    BUF6(1) = CHAR(IBIAS(L,IAE))
    END


 178. "File Access Error in File PASIBF.OID" Error 1004

 Product Version(s): 3.20 3.30 3.31 4.00
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 16-DEC-1987    ArticleIdent: Q23695

 Question:
    Why does pass three of the FORTRAN compiler generate the
 error message "File access error in file PASIBF.OID", error
 1004?

 Response:
    This error occurs because PASIBF.OID was never
 generated. In pass one, it is necessary to specify that you
 desire to make a .COD (combined source object) file. This
 is accomplished in Version 4.00 by using the /Fc switch.
 When pass three is implemented, it searches for the
 temporary file PASIBF.OID, which is generated only if you
 specify in pass one that you want a .COD file.


 179. P2 Assertion Error with -Gt

 Product Version(s): 4.00
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist4.00
 Last Modified:  1-JUN-1988    ArticleIdent: Q23639

    The following program causes a P2 assertion error only if compiled
 with -Gt:

     CHARACTER*5 ARROW2(2)
     INTEGER DIF2C(2600),DIF2OC(2),ZIFFHL(2),ZIFFLH(2),
    *COUNT(2),CHG1(5)
     INTEGER*1 KR2(2),PH2(2),PL2(2),WK2(2),YR2(2),QH2(2),QL2(2)
     WRITE(8,*)
    +COUNT(J),WK2(J),YR2(J),ARROW2(J),
    *CHG1(N21),CHG1(N22),CHG1(N23),CHG1(N24),CHG1(N25),CHG1(N26),
    * CHG1(N27),CHG1(N28),PH2(J),PL2(J),QH2(J),QL2(J),KR2(J),
    * DIF2C(J),DIF2OC(J),ZIFFHL(J),ZIFFLH(J)
     END

    There is no workaround for this problem.
    Microsoft is researching this problem and will post new information
 as it becomes available.


 180. Null Pointer Assignment Error at Compile Time with FORTRAN 4.0

 Product Version(s): 4.00
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist4.00 fixlist4.01
 Last Modified: 24-JUL-1990    ArticleIdent: Q23635

 Problem:

 The FORTRAN Version 4.00 Compiler generates the message "error 2001:
 Null pointer assignment" at compile time for the following program:

        character*64 chrfunc
        write(*,*)chrfunc()
        end

 Response:

 Microsoft has confirmed this to be a problem in Version 4.00 of the
 FORTRAN compiler. This problem was corrected in Version 4.01.

 The error 2001 comes from the first pass of the compiler. The error
 may be related to the presence of a null argument in the function
 argument list; adding the chrfunc function to return a character
 string gives back blanks. The problem is not affected by optimization,
 and apparently only affects character type.


 181. Internal Compiler Error: exphelp.c 1.55, Line 1102

 Product Version(s): 4.00
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist4.00 fixlist4.01
 Last Modified:  1-JUN-1988    ArticleIdent: Q23634

 Problem:
    The following program gives the assertion error "exphelp.c:1.55,
 line 1102" if compiled with -Od or -Odl (but not -Odct):

         REAL*8 EISKEW(6,3), BISKEW(3,6)
         COMMON /SKEW/   EISKEW
         EISKEW(I,J) = BISKEW(J,I)
         END

 Response:
    This is a known problem in Version 4.00 of the FORTRAN compiler.
 The problem was corrected in Version 4.01.
    The apparent reason for the failure is the assignment of a real*8
 array element that is not in COMMON to a real*8 array element that is
 in COMMON.
    The workaround is to compile -Odct or default.


 182. Compiler Error Message omf_ms.c:1.108, Line1078

 Product Version(s): 4.00
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist4.00
 Last Modified: 20-OCT-1988    ArticleIdent: Q23633

 Problem:

 The following code generates the omf_ms.c:1.108, line 1078 error
 message:

        DIMENSION ALS(10085)
        DIMENSION D1(2017)
        COMMON /LB1/ V(36,32), VHI
        EQUIVALENCE(V(1,1),ALS(1))
        EQUIVALENCE(ALS(1),D1(1))
        WRITE(6,210) VHI
   210  FORMAT(/1H,'POTENT. DIST.  VC=',F8.5)
        END

 Response:

 The problem is corrected if you do one of the following:

 1. Take V out of COMMON.

 2. Do not write VHI.

 3. Leave out the second EQUIVALENCE statement.

 4. Change the second EQUIVALENCE statement to
    "EQUIVALENCE(v(1,1),D1(1))".

 5. Combine the two EQUIVALENCEs into one, such as
    "EQUIVALENCE(V(1,1),ALS(1),D1(1))".


 183. Error F1039

 Product Version(s): 4.00
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified:  8-DEC-1987    ArticleIdent: Q23692

 Question:
    What does it mean when I get error F1039: "unrecoverable
 heap overflow in Pass3"?

 Response:
    This error indicates that the compiler ran out of
 dynamic memory space. The program may be too large or a
 subroutine may have too many symbols (thus it is running
 out of symbol space). This also will happen if your program
 is large and you are compiling with /Zi and /Od options.
    Currently, you can get around this problem by doing the
 following:

    1. Do not use the /Zi or /Od options with the Fl
 command.
    2. Break down the program into various source codes.


 184. Internal Compiler Error: loop.c 1.87, Line 836

 Product Version(s): 4.00
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist4.00
 Last Modified:  1-JUN-1988    ArticleIdent: Q23637

    The following code generates the loop.c:1.87, line 836 internal
 compiler error message:

    11      continue
            if (k1 .ne. k2) goto 20
            if (k .eq. 0) return
            if (k .ne. 2) goto 11
    20      continue
            end

    The error message occurs on the last line; if you compile with /Od
 or /Odct, the error no longer appears.

    This problem seems to be very specific; any attempt to rearrange
 the order of the three IF statements allows the program to compile.
 The pattern seems to be as follows:

    label-1
    IF jumping to label-2
    IF jumping to label-3
    IF jumping to label-1
    label-2
    label-3

    Please note that the program also will fail if the RETURN is
 replaced with a GOTO 30 and a 30 Continue is added after 20 Continue.
 A workaround is to rearrange the order of the IF statements.
    This is a known problem in Version 4.00.
    Microsoft is researching this problem and will post new information
 as it becomes available.


 185. Fixup Overflow L2002

 Product Version(s): 3.x 4.00 4.01 4.10 | 4.10
 Operating System:   MS-DOS             | OS/2
 Flags: ENDUSER |
 Last Modified: 21-JUL-1988    ArticleIdent: Q23663

    When you link your program, you may get the error message "L2002 fixup
 overflow." The following conditions can cause this error:

    1. A group is larger than 64K.
    2. The program contains an intersegment short jump or intersegment
       short call.
    3. The name of a data item in the program conflicts with that of a
       library subroutine included in the link.

    The most common of the three conditions is the first, i.e., one of
 the segments is over 64K; generally, it is the default data segment.
    To work around this problem, move data outside the default data
 segment. With Versions 4.x, use the /Gt compiler switch.
    This information is documented beginning on Page 232 of the
 "Microsoft FORTRAN Optimizing Compiler User's Guide" Versions 4.00,
 4.01, and 4.10. See the index for more references.
    For Versions 3.x, place data into named common blocks to move the
 data out of the default data segment.


 186. Getting Around Data Segment Limit

 Product Version(s): 3.2 3.3x 4.x
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified:  9-MAR-1988    ArticleIdent: Q23775

 Question:
    How do I get around the 64K data segment limit?

 Response:
    You can move arrays and local variables to a named
 common. You need to allocate data outside of the default
 data segment. When using a large memory model in Version
 4.0, use the /Gt option with the Fl command to place into a
 new segment those data items greater than or equal to the
 number of bytes specified.
    FORTRAN Version 4.00 and above can also use the HUGE
 memory model to allow individual data items (such as arrays
 and common blocks) to exceed 64K (using compiler option
 /AH). The HUGE keyword may also be used on individual data
 items that exceed 64K in LARGE model.


 187. Stack Overflow Error

 Product Version(s): 3.20 3.30 3.31 4.00
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 16-DEC-1987    ArticleIdent: Q23776

 Question:
    My program is failing with a stack overflow error. How
 can I get around it?

 Response:
    The program requires more stack than is available. You
 need to increase the size of the stack by using EXEMOD or
 the /STACK option at link time.
    If there is not enough space in the default data segment
 for the stack to grow, users of Versions 3.2, 3.3, and 3.31
 should do the following:

    1. Move the arrays and other variables into named common
 block.
    2. Use $LARGE metacommands.
    3. Move format statements into named common block.

    When using large memory model, Version 4.0 users should
 use the option /Gt (which defaults to 256 bytes) to place
 all data items greater or equal to 256 bytes outside the
 default data segment.


 188. Internal Compiler Error: regMD.c 1.74, Line 1304

 Product Version(s): 4.00
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist4.00
 Last Modified:  1-JUN-1988    ArticleIdent: Q23713

 Problem:
    The following code generates the compiler internal error message
 "regMD.c:1.74, line 1304":

    integer*2 i
    external i
    character x*127, y*15
    common /fred/ y
    y(17-i(x):)=x
    end

    The error is generated on the assignment statement. If I change
 integer*2 i to integer*4 i (or just delete it), the error is
 corrected.

 Response:
    This is a known problem in Version 4.00.
    Microsoft is researching this problem and will post new information
 as it becomes available.


 189. Internal Compiler Error: grammar.c, Line 91

 Product Version(s): 4.00   | 4.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | buglist4.00 fixlist4.01
 Last Modified: 21-JUL-1988    ArticleIdent: Q23708

    The following code fragment generates a compiler error in
 grammar.c, line 91:

          SUBROUTINE R(NROW,NCOL,NLAY,BUFF,IRCH)
          DIMENSION BUFF(NCOL,NROW,NLAY),IRCH(NCOL,NROW)
          DO 30 IR=1,NROW
          DO 30 IC=1,NCOL
          IL=IRCH(IC,IR)
          IF(IBD.EQ.1)BUFF(IC,IR,IL)=Q
    30    CONTINUE
       END

    Microsoft has confirmed this to be a problem in Version 4.00. This
 problem was corrected in Version 4.01.
    The program gives an internal compiler error that will disappear
 when compiled with -Odclt. Using -Odclt when compiling is the easiest
 workaround.


 190. FORTRAN: Bad Code Generated with /Ot

 Product Version(s): 4.01 4.10 | 4.10
 Operating System:   MS-DOS    | OS/2
 Flags: ENDUSER | buglist4.01 buglist4.10 fixlist5.00
 Last Modified: 16-JUN-1989    ArticleIdent: Q28653

 If you compile the following code with the default optimization, /Ot,
 bad code is generated for the line "DO 19999 Y=N, 1, -1." If this
 sample is compiled with /Od to disable optimizations, correct code is
 generated.

          INTEGER CL
          PARAMETER(CL=12)
          INTEGER  X,Y
          REAL FLD(101,101)
          CHARACTER   BFR*101, LEVEL*26
          DATA  LEVEL/'ABCDEFGHIJKLMNOPQRSTUVWXYZ'/
    101   FORMAT(A1,'FIELD'/)
    102   FORMAT(' ',A101)
          DO 10 I=1,101
            FLD(I,I) = 1.0
    10    CONTINUE
          N=101

          DO 19999 Y=N,1,-1

          DO 19998 X=1,N
              IDX=50.0*FLD(X,Y)
              IF(MOD(IDX,2).NE.0) GO TO 19996
             CONTINUE
             IDX=(IDX/2)+1
             IF((IDX.GE.1).AND.(IDX.LE.26)) GO TO 19992
             GO TO 19993

    19992 CONTINUE
          BFR(X:X)=LEVEL(IDX:IDX)
          GO TO 19994
    19993 CONTINUE
          BFR(X:X)='*'
    19994 CONTINUE
          GO TO 19997
    19996 CONTINUE
          BFR(X:X)=' '
    19997 CONTINUE
    19998 CONTINUE
          WRITE(*,102) BFR(1:N)
    19999 CONTINUE
          RETURN
          END

 Microsoft has confirmed this to be a problem in Versions 4.01 and
 4.10; the problem was corrected in Version 5.00.


 191. Reading and Writing to I/O Ports

 Product Version(s): 3.20 3.30 3.31 4.00
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 16-DEC-1987    ArticleIdent: Q23885

 Question:
    How can I read from and write to the communication
 ports?

 Response:
    In order to read from or write to the communication
 ports using FORTRAN, it is necessary to use a special
 device driver. You may have to write the device driver
 yourself, in assembly language.
    To read information from the communication ports also
 requires an assembly language interrupt handler, which is
 very complicated. It is necessarily complicated due to the
 nature of device handshaking, which is required in order to
 read but not always in order to write.


 192. Internal Compiler Error: regMD.c 1.79, Line 1507

 Product Version(s): 4.01 4.10 | 4.10
 Operating System:   MS-DOS    | OS/2
 Flags: ENDUSER | buglist4.01 buglist4.10 fixlist5.00
 Last Modified:  6-NOV-1989    ArticleIdent: Q28659

 The following internal compiler error is generated by the code
 given below:

    regmdc.for(3) : fatal error F1001: Internal Compiler Error
                    (compiler file '@(#)regMD.c:1.79', line 1507)
                    Contact Microsoft Technical Support

 The compiler switch /Odclt turns on all optimization but does not
 disable alias checking, as demonstrated in the following code:

       COMMON X(10),A,B
       J=2
       DO 40 I=1,B
       GO TO (10,20,30) , J
 10    IF(X(I).EQ.A) K=0
 20    IF(X(I).EQ.A) K=0
 30    IF(X(I).EQ.A) K=0
 40    CONTINUE
       END

 The workaround is to compile with the compiler switch /Odclt.

 Microsoft has confirmed this to be a problem in Versions 4.01 and
 4.10 of the FORTRAN compiler. This problem was corrected in Version
 5.00.


 193. FORTRAN Compiler Error D1001: "Could Not Execute F1.EXE"

 Product Version(s): 4.x
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 16-JUN-1988    ArticleIdent: Q23883

 Problem:
    When I compile my program, I get the following message:

    error D1001: could not execute F1.EXE

 Response:
    The specified file containing a compiler pass or the linker is
 found, but for some reason cannot be executed. Any of the following
 items can cause this problem:

    1. The F1.EXE file cannot be found. You may have a
 terminate-and-stay-resident program that can alter the setting of the
 environment variable PATH. PATH indicates the location of F1.EXE.
    2. There is not enough memory.
    3. You have a bad F1.EXE file with illegal .EXE file format.
    4. DOS and COMMAND.COM are incompatible. If their version numbers
 are different, the compiler may not be able to open the intermediate
 file. This means the COMMAND.COM command processor cannot create the
 TMP directory for the compiler intermediate file.


 194. Loop Optimization Does Not Preserve CX When Calling NINT

 Product Version(s): 4.01 4.10 5.00 | 4.10 5.00
 Operating System:   MS-DOS         | OS/2
 Flags: ENDUSER | buglist4.01 buglist4.10 fixlist5.00
 Last Modified:  7-NOV-1989    ArticleIdent: Q28667

 Using FORTRAN Versions 4.01 and 4.10 with optimization "On" to compile
 the simple loop generates bad code, which will give a run-time error.

 To correct this problem, use /Odct (disables loop optimization) when
 compiling.

 Microsoft has confirmed this to be a problem in Versions 4.01 and
 4.10 of the FORTRAN compiler. This problem was corrected in Version
 5.00.

 The following code demonstrates the problem:

       PROGRAM TEST
       DIMENSION X(9), NX(9)
       DATA X/ 1.1, 2.2, 3.3, 4.4, 5.5, 6.6, 7.7, 8.8, 9.9/

       DO 100 I=1, 9
       100 NX( I ) = NINT( X( I ) )

       STOP
       END

 With optimization on, the index becomes corrupted because it is
 contained in the CX register; the index is really a loop counter. CX
 is set to nine and is decremented during each pass until it reaches 0
 (zero).

 The index for NX is the SI register; for the X array, the DI
 register is used. When you call the intrinsic function NINT, the CX
 register is not preserved. It contains a bad value after returning to
 the main program, which causes the loop to disappear when the main
 program tries to decrement CX.

 Note that there are a number of run-time errors that can occur. They
 are usually math related errors, such as M6101 <invalid operation> and
 M6201 <domain error>.


 195. Incorrect INTEGER Parameters in the Source

 Product Version(s): 4.00
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist4.00
 Last Modified:  1-JUN-1988    ArticleIdent: Q23957

    INTEGER*2 variables that have been assigned values in a parameter
 statement sometimes are listed incorrectly in the source listing. The
 following code is an example:

    PROGRAM TEST
      INTEGER*2
      PARAMETER(I=300)
      END

    In the source listing, "I" is listed as having a value of 44.
    When INTEGER*2 variables are assigned values greater than 256 in a
 parameter statement, they show up as value mod 256 in the source
 listing. However, the values are used correctly in the code. This
 problem will be corrected in the next release.


 196. Run-Time Error 6500 on File Names Similar to Special Devices

 Product Version(s): 4.00
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist4.00 fixlist4.01
 Last Modified:  9-JUN-1988    ArticleIdent: Q23906

    When attempting to READ from file "PRM.DAT", the run-time error
 F6500, "file not open for reading or file locked" is received.
    Microsoft confirmed this to be a problem in Version 4.00 of the
 FORTRAN compiler. This problem was corrected in Version 4.01.
    The run-time compiler thinks it is dealing with file "PRN". This
 error affects all of the special devices (AUX, CON, NUL, and PRN).
 Examples of this problem are as follows:

    1. READing from "PRM" gives error 6500.
    2. WRITing to "COL" writes to "CON".
    3. WRITing to "NUM" produces no output (like NUL).

    The workaround for this problem is not to use any file names that
 are similar to any of the special device names, e.g. AUX, CON, NUL,
 and PRN.


 197. Integer Versus Character Comparisons

 Product Version(s): m4.00
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 20-OCT-1988    ArticleIdent: Q23941

 Problem:

 While the MS-DOS FORTRAN Optimizing Compiler allows the comparison of
 Character variables with Integer variables, some care should be taken
 to perform the proper comparison.

 As an example, you might expect the following program to produce two
 ".TRUE." comparisons. In one case, the Character variable is compared
 against an Integer variable containing a Character constant and, in
 the second case, an Integer variable contains the ASCII value
 corresponding to the same character.

        CHARACTER*4 C4
        C4 = 'A'
        I4 = 'A'
        WRITE (*,'(1X,A,Z8,A,Z8,A)') 'C4 IN HEX=<',C4,'>  I4 IN HEX=<',
     +  I4,'>'
        WRITE (*,*) 'C4 .EQ. I4? ',C4 .EQ. I4
        I4 = #41
        WRITE (*,'(1X,A,Z8,A,Z8,A)') 'C4 IN HEX=<',C4,'>  I4 IN HEX=<',
     +  I4,'>'
        WRITE (*,*) 'C4 .EQ. I4? ',C4 .EQ. I4
        END

 Response:

 That assumption is incorrect, as evidenced by the hexadecimal
 representation of the value of the I4 variable. The following is the
 output from the program:

    C4 IN HEX=<41202020>  I4 IN HEX=<20202041>
    C4 .EQ. I4? T
    C4 IN HEX=<41202020>  I4 IN HEX=<00000041>
    C4 .EQ. I4? F

 When the Character constant "A" is assigned, the unused three
 positions remaining in I4 are filled with blank characters
 (hexadecimal value 20). If the ASCII value equivalent to "A"
 (hexadecimal value 41) is assigned to I4, the remaining three
 positions are filled with zeros. Thus, the first comparison will
 succeed, while the second will fail.

 Please note that this caution does not apply to comparisons between
 Character and Integer*1 variables. Because no padding is necessary,
 the comparisons always will be correct.


 198. Problem with INCLUDE and LST Files

 Product Version(s): 4.00
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist4.00 fixlist4.01
 Last Modified: 16-JUN-1988    ArticleIdent: Q24061

    If you compile a FORTRAN program that contains an INCLUDE file, as
 in the example below, the $LIST fails to turn listing back on until
 the symbol table listings at the bottom. The INCLUDE file does not
 have a CTRL-Z in it.
    The following is an example:

    $NOLIST
                 INTEGER*2 INUM,X,Y
    $LIST

    This problem was corrected in Version 4.01.


 199. Help and Arg Compile "Not an Editor Switch"

 Product Version(s): 5.00    | 5.00
 Operating System:   MS-DOS  | OS/2
 Flags: ENDUSER |
 Last Modified:  6-DEC-1989    ArticleIdent: Q46262

 The following messages can be generated when the Microsoft Editor (M)
 is set to use the Quick configuration:

    Help is not an editor switch
    Argcompile is not an editor switch

 The following two lines must be deleted from the TOOLS.INI file to
 correct this problem:

    Argcompile:F5  (delete only the first occurrence of this)

    Help:F1

 Argcompile is correctly defined later in the TOOLS.INI file. Help is
 defined by default.


 200. $PAGE Metacommand Occasionally Does Not Work

 Product Version(s): 4.00
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist4.00 fixlist4.01
 Last Modified:  1-JUN-1988    ArticleIdent: Q24172

    The $PAGE metacommand is supposed to begin a new page in the
 source-listing file, but occasionally it fails to do so.
    This problem was corrected in FORTRAN Version 4.01. There is no
 known workaround.


 201. Sending a File with a Control Character to the Printer

 Product Version(s): 3.20 3.30 3.31 4.00
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 20-OCT-1988    ArticleIdent: Q24212

 Question:

 When I send a control character to a file, then send that file to the
 printer, the control character is printed out. How do I get around
 this situation?

 Response:

 Carriage control characters are not used for disk files. Any character
 you send to a disk file actually appears in the disk file; therefore,
 the first character appears instead of being used for carriage
 control.

 If you want to produce a disk file that causes the printer to form
 feed when it is printed, you must insert a form feed character into
 the file itself. The ASCII form feed character is decimal 12, so you
 can write this into a file. For instance, the following program
 inserts a form feed character into the disk file "test":

        open(6,file = 'test', status = 'new')
        write(6,*) 'hello'
        write(6,1) char(12)
    1   format(a1)
        write(6,*) 'there'
        end

 When printed, "hello" will show on the first page of output, the
 printer will form feed, and "there" will be on the second page of
 output.


 202. Compiler Error "Omf_ms.c:1.108, Line 1078"

 Product Version(s): 4.00
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist4.00 fixlist4.
 Last Modified: 31-MAY-1988    ArticleIdent: Q24287

    The following code produces the error "omf_ms.c:1.108, line 1078",
 if compiled without option -Od. If compiled with option -Od, the code
 produces this error as well as "error omf_ms.c:1.108 line 2458". Thus,
 the -Od option adds to the problem. The following is the code:

    INTERFACE TO SUBROUTINE A

    END
    INTERFACE TO SUBROUTINE B(X)
    EXTERNAL X
    END
    CALL A
    CALL B(A)
    END

    This is a confirmed problem in Version 4.00 of the compiler. This
 problem was corrected in Version 4.01.


 203. Internal Compiler Error: mactab.c 1.30, Line 647

 Product Version(s): 4.00
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist4.00
 Last Modified:  1-JUN-1988    ArticleIdent: Q24214

 Problem:
    The following code generates the internal compiler error
 mactab.c:1.30, line 647:

    complex*16 z1,z2,z3
    z1=z1*dconjg(z2) *z3
    end

    If you use a temporary variable to hold the result of the function,
 the error is corrected (the intrinsic function dconjg returns the
 conjugate of a complex16 number).

 Response:
    This is a known problem in Version 4.00.
    The only workaround is to not use COMPLEX*16. Using COMPLEX*8
 causes no error.


 204. Error F1043

 Product Version(s): 4.00
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 29-SEP-1988    ArticleIdent: Q24213

 Problem:

 When I run the compiler, it generates "error F1043: cannot open
 compiler intermediate file".

 Response:

 The compiler was unable to open an intermediate file. There are two
 possible causes, as follows:

 1. The environment variable TMP was set to a nonexistent
    directory. Try not setting TMP at all, or setting TMP to an
    existing directory, as follows:

    tmp=[drive:existent directory]     ;no spaces after tmp

 2. There is not enough space on the hard disk or you have
    a terminate-and-stay-resident program loaded in memory.


 205. Compile Time Error F1901

 Product Version(s): 4.00
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 20-OCT-1988    ArticleIdent: Q24383

 Question:

 Why did I receive F1901 compiler error: "program too large for
 memory"?

 Response:

 One reason why you received this error message may be that the FORTRAN
 program is too large for memory and needs to be broken into smaller
 subprograms, then linked together.

 Also, the message may be due to multiple definitions of the program
 name. The following is an example:

        Program TEST
        Common /TEST/

 Finally, the message may be due to the way FORTRAN keeps track of
 variables that are not explicitly given a type. FORTRAN allows you to
 have variable declarations anywhere in the declaration block and
 variables can have a default type. Variables starting with I-N are
 assumed to be integer; the others are assumed to be real variables.
 The following is an example:

        DIMENSION X(10),I(20)
        EQUIVALENCE (X(1),I(1))

 Unless the X and I arrays are explicitly given a type, the compiler
 must remember what type they are until the end of the declaration
 block. It is this necessity of saving the type information that can
 cause you to run out of memory. Those programs that receive this error
 (from the first pass of the compiler) should compile normally if the
 arrays are explicitly typed. The previous example would then be as
 follows:

        REAL X(10)
        INTEGER I(20)
        EQUIVALENCE (X(1),I(1))

 Some guidelines to lessen the chance of getting a "program too big"
 error are the following:

 1. Explicitly type arrays (especially those used in EQUIVALENCE
    statements).

 2. Concerning array bounds (10, 20, and 1 in the examples), use as few
    unique values as possible and mention the most frequently used
    bounds as soon as possible.

 3. The following program organization is recommended:

       type statements
       EXTERNAL statements
       DIMENSION statements
       COMMON statements
       EQUIVALENCE statements
       DATA statements


 206. Using FORTRAN 3.13 or 3.2 with an 80286 AT-class machine

 Product Version(s): 3.13 3.20
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified:  6-DEC-1989    ArticleIdent: Q24418

 Problem:

 My FORTRAN Versions 3.13 and 3.20 programs work properly on an IBM-XT,
 but when I run the programs on an AT or AT clone, all zeros are
 generated.

 Response:

 If you do not have the 80287 numeric coprocessor with your 80286, you
 can experience problems with floating-point calculations.

 For Version 3.20, the following corrects this problem. If you do not
 have a coprocessor and you link with the default MATH library
 (MATH.LIB), you must explicitly tell MATH.LIB that there is no
 coprocessor by issuing the following command in DOS before running the
 program:

    SET NO87=8087 Suppressed

 This command forces the use of the floating-point emulation software.
 This action is necessary because an AT with no coprocessor fools
 MATH.LIB into thinking that there is a coprocessor present. This
 behavior causes the MATH.LIB to return incorrect results.

 Additional information about this SET command is available in the
 README.DOC file on the MS-DOS FORTRAN distribution disk.

 You do not need to use this SET command if you do the following:

 1. Link with ALTMATH.LIB or DECMATH.LIB, which do not use or look for
    the coprocessor.

 2. Use the modified Version 3.20 with math libraries enclosed.

 FORTRAN Version 3.13 does not recognize the NO87 environment variable;
 therefore, if you use this version, you must link with the enclosed
 modified library Version 3.13.

 Note: The patch includes the specially modified math libraries that
 can operate normally on the 80286 whether or not there is a
 coprocessor present. With Version 3.20 of Microsoft FORTRAN, use
 MATH.LIB and 8087.LIB. With Microsoft FORTRAN Version 3.13, use
 FORTRAN.LEM and FORTRAN.L87.


 207. $TITLE and $SUBTITLE not taking effect in LST files

 Product Version(s): 4.00 4.01 4.10 5.00 | 4.10 5.00
 Operating System:   MS-DOS              | OS/2
 Flags: ENDUSER | buglist4.00 buglist4.01 buglist4.10 fixlist5.00
 Last Modified:  7-NOV-1989    ArticleIdent: Q24427

 $TITLE and $SUBTITLE are not taking effect in the LST file.

 $TITLE:"This is the main" was added to the first line of DEMO.FOR, and
 $SUBTITLE:"This is the subroutine" was added to the 28th line.
 However, "This is the main" is not printed at the top of the listing,
 and "This is the subroutine" is not printed before the subroutine.

 Microsoft has confirmed this to be a problem in Versions 4.00, 4.01,
 and 4.10 of the FORTRAN compiler. This problem was corrected in
 Version 5.00.


 208. Run-Time Hang from the Use of the EOF Function

 Product Version(s): 4.00
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist4.00 fixlist4.01
 Last Modified:  1-JUN-1988    ArticleIdent: Q24429

    The following program will cause your computer to hang when
 compiled with FORTRAN Version 4.00:

            LOGICAL X
            OPEN(1)
            DO 1 I=1,10000
            X = EOF(1)
    1       CONTINUE
            END

    Microsoft has confirmed this to be a problem in Version 4.00 of the
 FORTRAN compiler. It was corrected in Version 4.01.
    Each call to the EOF intrinsic function costs two bytes from the
 stack. The program may run properly if the run-time stack size is
 greater than two times the number of calls to EOF; therefore, a
 possible workaround is to raise the run-time stack size (via EXEMOD).


 209. Problem with FX.0

 Product Version(s): 4.00
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist4.00 fixlist4.01
 Last Modified:  1-JUN-1988    ArticleIdent: Q24428

    Numbers with a value of less than .1 appear incorrectly when
 written in F10.0 format, as illustrated in the following code example:

           A=0.03
           WRITE(*,10) A
    10     FORMAT(1X,F10.0)
           END

    The output of the program is two.
    Microsoft confirmed this to be a problem in Version 4.00 of the
 FORTRAN compiler. The problem was corrected in Version 4.01.


 210. The Optimizer and Arrays Greater Than 32K

 Product Version(s): 4.00
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist4.00 fixlist4.01
 Last Modified:  1-JUN-1988    ArticleIdent: Q24426

    The following program causes an infinite loop (if $STORAGE:2 is
 included, it loops through only once):

               INTEGER*2 BIGARY(8000,3),I,J,KOUNT
               KOUNT=0
               DO 100 J=1,3
                 DO 50 I=1,8000
                   BIGARY(I,J) = 1
                   KOUNT= KOUNT + 1
  50             CONTINUE
               WRITE(*,*)'KOUNT = ', KOUNT
  100          CONTINUE
               END

    Microsoft confirmed this to be a problem in Version 4.00 of the
 FORTRAN compiler. This problem was corrected in Version 4.01.


 211. Compile Time Warning F4803 on ENTRY Statement in FUNCTION

 Product Version(s): 4.00 4.01
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist4.00 buglist4.01 fixlist4.10
 Last Modified:  1-JUN-1988    ArticleIdent: Q24628

    According to Section 15.7.3 of the ANSI standard, variables
 corresponding to entry names and the function of the same type should
 be associated; defining one defines all of them. However, the
 following program produces the warning message "warning F4803: GRONK :
 FUNCTION : return variable not set" when compiled:

    function grot(z,y)
    grot=z*(z-y)
    return
    entry gronk(z,y)
    grot=z*z+y
    return
    end

    program thing
    write (*,*) 'The answer is...'
    write (*,*) gronk(3.5,1.0)
    end

    This is a known problem in Versions 4.00 and 4.01 of the FORTRAN
 compiler. This problem was corrected in Version 4.10.
    The workaround for Version 4.01 is to define a return variable
 "gronk".


 212. Concatenation (//) with the Target Variable on the Right

 Product Version(s): 4.00 4.10 5.00
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 13-JUL-1990    ArticleIdent: Q24618

 Problem:

 Below is a program fragment which appears to generate incorrect
 results when using a concatenation operator:

        CHARACTER*20 CH
        CH = 'B'
        CH = 'A'//CH       <-- string concatenation

 CH equals 'AA' after the concatenation operation and not the
 expected 'AB'.

 Response:

 It is strictly against the FORTRAN 77 standard to have the target
 variable, in this case CH, on the right side of the assignment.

 Referencing the assignment statement

    v = e

 page 10-3, lines 5-6, of the FORTRAN 77 standard states

    None of the character positions being defined in v may be
    referenced in e.

 The character positions defined by CH (v in the ANSI standard) in
 the code above are also referenced in CH (e in the ANSI standard),
 making this operation illegal.

 An additional 32K of memory would have to be allocated for temporary
 storage to make this a legal operation.


 213. Problem with Heap Allocator

 Product Version(s): 3.31
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 24-JUL-1990    ArticleIdent: Q24728

 Question:
    Why does FORTRAN Version 3.31 crash at compile time or when generating
 strange and erroneous error messages?

 Response:
    The Version 3.31 compiler stack size has been increased to 40K, and it
 causes erroneous errors at compile time. You will get one of the following
 error messages:

    1. Null Pointer Assignment
    2. Error : Compiler Invalid Pointer Range
    3. Will hang on FOR1
    4. Divide Overflow

    To work around this problem, decrease the size of the stack for FOR1.EXE t
 about 20K or 30K using EXEMOD, or specify that the compiler create a listing
 file.


 214. Calling Other Programs

 Product Version(s): all
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 31-AUG-1987    ArticleIdent: Q24736

 Question:
    How can I run another program from my FORTRAN program?

 Response:
    The method for running another Program from the FORTRAN program varies for
 different FORTRAN versions.
    For Version 3.3 and 3.31 users, use the library called CEXEC.LIB that has
 been added for system and spawn support. CEXEC.LIB, a subsidiary of the C
 library, can be used to run other programs. The CEXEC.LIB library has to be
 typed in explicitly.
    For Version 4.0 users, the FORTRAN run-time libraries MLIBFORx.LIB and
 LLIBFORx.LIB include the system routine and a subset of the spawnlp routine
 (as well as other routines) from the C library. FORTRAN programs can access
 these routines in the FORTRAN run-time libraries. The demonstration program
 DEMOEXEC.FOR, included with the Microsoft FORTRAN Compiler, also gives
 examples of how to call these routines.


 215. FORTRAN 4.10 FLOPSET.DOC File, Setup on Floppies

 Product Version(s): 4.10   | 4.10
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified: 28-APR-1988    ArticleIdent: Q28720

    The following information concerns the FORTRAN Version 4.10
 FLOPSET.DOC file:

 FLOPSET.DOC -- Removable Disk Setup Information
 (C) Copyright Microsoft Corporation, 1987

    The following information replaces Sections 2.4.4 and 2.4.5 of the
 Microsoft(R) FORTRAN Optimizing Compiler User's Guide.

 Installing on a 5 1/4-Inch Disk System
    Before you install the compiler on a 5 1/4-inch disk system, you
 should format at least eight blank disks. SETUP uses seven blank disks
 for the compiler software and libraries. In addition, you should copy
 source programs, including the DEMO.FOR demonstration program, to the
 eighth blank disk. Table 2.1 shows how SETUP organizes your 5 1/4-inch
 disks.
     If you request compatibility with Versions 3.20 and 3.30 of
 Microsoft FORTRAN, SETUP requires a ninth blank disk (which becomes
 the Compatibility disk), to which it copies the compatibility library,
 FORTRAN.LIB. This disk can be either a formatted blank disk or a disk
 with earlier-version object files that you want to link. Be sure to
 label the disk before using it with SETUP.

 Installing on a 3 1/2-Inch Disk System
    Before you install the compiler on a 3 1/2-inch disk system, format
 at least five blank disks. SETUP uses four blank disks for the
 compiler software and libraries. In addition, you should copy source
 programs, including the DEMO.FOR demonstration program, to the fifth
 blank disk. Table 2.2 shows how SETUP organizes your 3 1/2-inch disks.

 Table 2.1
 Organization for 5 1/4-Inch Disks
 --------------------------------------------------------------------------
 Disk Name           Files           File Contents
 --------------------------------------------------------------------------
 Driver              FL.EXE          Executable file for the FL command
                     FL.ERR          Error-message file for the FL command
                     FL.HLP          FL command help file
                     F1.EXE          Pass 1 of the compiler
                     F1.ERR          Error-message file for Pass 1 of the
                                     compiler
 Compiler 1          F2.EXE          Pass 2 of the compiler
                     F23.ERR         Error-message file for Passes 2 and 3
                                     of the compiler
 Compiler 2          F3.EXE          Pass 3 of the compiler
                     F3S.EXE         Alternate Pass 3 of the compiler. This
                                     pass is used if optimization is dis-
                                     abled during compiling. (See Section
                                     3.3.15, "Optimizing," of the User's
                                     Guide for more information.)
                     F23.ERR         Error-message file for Passes 2 and 3
                                     of the compiler
 Link                LINK.EXE        Executable file for the linker
                     xLIBFORx.LIB    Library created by SETUP
 Utility             LIB.EXE         Executable file for the LIB utility
                     MAKE.EXE        Executable file for the MAKE utility
                     EXEPACK.EXE     Executable file for the EXEPACK utility
                     EXEMOD.EXE      Executable file for the EXEMOD utility
                     ERROUT.EXE      Executable file for the ERROUT utility
                     SETENV.EXE      Executable file for the SETENV utility
 Debug               CV.EXE          Executable file for the Microsoft
                                     CodeView(R) debugger for MS-DOS
                     CV.HLP          Help file for the CodeView debugger
                                     for MS-DOS(R)
                     CVPACK.EXE      Executable file for the CVPACK utility
 Scratch             LIB.EXE         Executable file for the LIB utility,
                                     which is used to help build the
                                     run-time library. SETUP installs
                                     this file on this disk.
                     Intermediate    Present while SETUP is running;
                     versions of     deleted from the disk when SETUP
                     libraries       finishes normally
 ----------------------------------------------------------------------------

 Table 2.2
 Organization for 3 1/2-Inch Disks
 ----------------------------------------------------------------------------
 Disk Name           Files           File Contents
 ----------------------------------------------------------------------------
 Driver/Compiler     FL.EXE          Executable file for the FL command
                     FL.ERR          Error-message file for the FL command
                     FL.HLP          Help file for the FL command
                     F1.EXE          Pass 1 of the compiler
                     F1.ERR          Error-message file for Pass 1 of the
                                     compiler
                     F2.EXE          Pass 2 of the compiler
                     F23.ERR         Error-message file for Passes 2 and 3
                                     of the compiler
                     F3.EXE          Pass 3 of the compiler
 Link                F3S.EXE         Alternate Pass 3 of the compiler. This
                                     pass is used if optimization is dis-
                                     abled during compiling. (See Section
                                     3.3.15, "Optimizing," of the User's
                                     Guide for more information.)
                     F23.ERR         Error-message file for Passes 2 and 3
                                     of the compiler
                     LINK.EXE        Executable file for the linker
                     xLIBFORx.LIB    Library created by SETUP
 Utility             LIB.EXE         Executable file for the LIB utility
                     MAKE.EXE        Executable file for the MAKE utility
                     EXEPACK.EXE     Executable file for the EXEPACK utility
                     EXEMOD.EXE      Executable file for the EXEMOD utility
                     ERROUT.EXE      Executable file for the ERROUT utility
                     SETENV.EXE      Executable file for the SETENV utility
                     CV.EXE          Executable file for the Microsoft
                                     CodeView debugger for MS-DOS
                     CV.HLP          Help file for the CodeView debugger
                                     for MS-DOS
                     CVPACK.EXE      Executable file for the CVPACK utility
 Scratch             LIB.EXE         Executable file for the LIB utility,
                                     which is used to help build the
                                     run-time library. SETUP installs
                                     LIB.EXE on this disk.
                     Intermediate    Present while SETUP is running;
                     versions of     deleted from the disk if SETUP
                     libraries       finishes normally
 -----------------------------------------------------------------------------


 216. Error F6601: Direct Record Overflow on Rewind

 Product Version(s): 4.01
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist4.01
 Last Modified:  1-JUN-1988    ArticleIdent: Q25009

    The following source code will generate run-time error F6601:

    open(file='test',access='direct',recl=50,status='unknown')
    write(5,rec=4) 'hello'
    endfile 5
    rewind(5)
    end

    This is a known problem in Version 4.01.
    Microsoft is researching this problem and will post new information
 as it becomes available.


 217. Appending to CTRL-Z-Terminated File

 Product Version(s): 4.01
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist4.01 fixlist4.10
 Last Modified: 31-MAY-1988    ArticleIdent: Q25010

 Problem:
    Attempting to append to a CTRL-Z-terminated file causes the file
 pointer to be positioned in an incorrect record. The typical symptom
 associated with this problem is that the first character of a file
 will be duplicated when the file is appended to.
    For example, a CTRL-Z-terminated file which contains the characters
 ABC will appear as AABCDEF when DEF is appended to it.

 Response:
    Microsoft has confirmed this to be a problem in Version 4.01 of the
 FORTRAN compiler.
    This problem was corrected in Version 4.10.


 218. Programs Executed by PAUSE Statements

 Product Version(s): 4.01
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist4.01
 Last Modified:  1-JUN-1988    ArticleIdent: Q25110

 Problem:
    When my program executes a second program following a PAUSE
 statement, input to the second program cannot be redirected from a
 file. For example, if the following program named fort1.for:

        pause
        end

 executes the following program named fort2.for:

        read(*,*) i,j
        read(*,*) k,l
        write(*,*) 'i,j,k,l=',i,j,k,l
        end

 and I want to obtain input for fort2.for from a file named fort2.dat,
 the following sequence of steps causes an end-of-file error:

        fort1
              pause - Please enter a blank line (to continue) or DOS
                      COMMAND
        fortr2 < fort2.dat

 Response:
    This error occurs because the child program, fort2, inherits file
 handle attributes from the parent program, fort1. Because you did not
 specify redirection for fort1, the run-time system assumes that fort2
 also does not use redirection.
    The workaround is to create a data file containing the command line
 that redirects input to the child program. For the above example,
 construct a data file named fix.dat containing the following
 statement:

    fort2 < fort2.dat

    Use this new data file as input when running the parent program.
 For the example above, run fort1 using following command line:

     fort1 < fix.dat

    This command line causes the PAUSE command to take its input from
 fix.dat and causes fort2 to recognize that its input has been
 redirected. This allows fort2 to take its input from fort2.dat.
    This is a known problem in Version 4.01.
    This feature is under review and will be considered for inclusion
 in a future release.


 219. FORTRAN 4.10 README.DOC: Requesting Assistance from Microsoft

 Product Version(s): 4.10   | 4.10
 Operating System:   MS-DOS | OS/2
 Flags: PSSONLY | ENDUSER
 Last Modified: 30-OCT-1990    ArticleIdent: Q28721

 The following section of the FORTRAN README.DOC file provides
 information regarding reporting problems with the compiler.

 README.DOC -- (C) Copyright Microsoft Corporation, 1987, 1988
 Microsoft(R) FORTRAN Optimizing Compiler Version 4.10

 This document contains information about Version 4.10 of the
 Microsoft(R) FORTRAN Optimizing Compiler and libraries. Microsoft
 updates its documentation when it is reprinted, so you may find that
 some of the information in this file has already been included in your
 manuals.

 NOTE

 Microsoft CodeView(R) and the utilities have a separate readme
 file, CVREADME.DOC, on the CodeView for MS-DOS disk.

 REQUESTING ASSISTANCE FROM MICROSOFT -- (206) 454-2030

 When reporting problems with the compiler, please provide Microsoft
 Corporation with the following information to help in tracking down
 the problem:

    *   The compiler version number (from the logo that appears on the
        screen when you invoke the compiler using the FL command).

    *   The version of DOS you are running (use the VER command in DOS).

    *   Your system configuration (the machine, total memory, and total free
        memory at compiler execution time).

    *   The command line used in the compilation.

    *   All object files/libraries used to link, if necessary. You need
        not provide standard object files/libraries, but please state which
        ones you are using.

 Having this information will help solve your problem quickly.


 220. Converting Decimal Floating Point to IEEE Format

 Product Version(s): 4.01
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 16-OCT-1987    ArticleIdent: Q25112

 Question:
    A program I compiled with Version 4.01 reads data files by a program
 compiled with Version 3.2 and decmath.lib. However, Version 4.01 no longer
 supports decmath.lib. Is there any way for me to read the data file?

 Response:
    Since you know the ordering of the variables in the files, you can convert
 the file by doing the following:

    1. Using a Version 3.2 program compiled with $decmath, read the old data
 file, and write a new file using formatted writes.
    2. Using a Version 4.01 program or a Version 3.2 program compiled without
 $decmath, read the new formatted file, and write a new unformatted (or binary
 whichever was used) file.


 221. Optimization Problem

 Product Version(s): 4.01
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist4.01
 Last Modified:  7-OCT-1988    ArticleIdent: Q25113

 Problem:

 In the program fragment below, no code is generated for the assignment
 hibyt=hold. This problem does not occur if optimization is turned off
 or if line 36 is moved between lines 33 or 34. The statements are as
 follows:

    33  lowbyt=hold
    34  lowbyt=iand(lowbyt,lowmsk)
    35  call output(datprt,lowbyt)
    36  hibyt=hold
    37  hibyt=ishift(iand(hibyt,himsk),shift)
    38  call output(datprt,hibyt)

 Response:

 Microsoft has confirmed this to be a problem in Version 4.01. We are
 researching this problem and will post new information as it becomes
 available.


 222. "Invalid Object Module" Error

 Product Version(s): 4.01
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist4.01
 Last Modified:  1-JUN-1988    ArticleIdent: Q25114

 Problem:
    When the following code is compiled with default options, the error
 "invalid object module at link time" is generated.

    character*128 string
    dimension string(640)
    data string/640*'help'/
    string(1)='bug'
    end

    The error is not generated when the last three lines are rewritten
 as follows:

     do 10 i=1,640
       string(i)='help'
 10  continue
     string(1)='bug'
     end

 Response:
    This is a known problem in Version 4.01 of the FORTRAN compiler.
    The error will exhibit itself if you try to initialize more than
 one CHARACTER array element with a size greater than 127 bytes.
    This problem can be worked around by reducing CHARACTER size below
 128 or initialize the array by using assignment statements.


 223. Large Arrays and Entry Statements

 Product Version(s): 4.01
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist4.01
 Last Modified:  1-JUN-1988    ArticleIdent: Q25115

    After returning from the initial subroutine call and reentering
 through ENTRY statements, "incorrect address" is passed for the
 following code:

     real*4 a(20000)
     common /m1/m
     m=20000
     do 10 i=1,m
      a(i)=i
 10  continue
     call sub1(a)
     call el
     end

     subroutine sub1(a)
     real*4 a(m)
     common /m1/m
     write(*,*) a(1), a(m),m
     return
     entry el
     call e2
     return
     end

    This code works correctly if the variable m is not in common.
    This is a known problem in Version 4.01.
    Microsoft is researching this problem and will post new information
 as it becomes available.


 224. Concatenation Results Passed to Function

 Product Version(s): 4.01
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist4.01
 Last Modified:  1-JUN-1988    ArticleIdent: Q25133

    The concatenation operation will not pass the proper results to the
 formal argument when used within a function call. The proper results
 seem to be followed by part of the copyright message instead of
 blanks. The following program demonstrates this problem:

         CHARACTER*80 FUNCTION OKPLT(X)
         CHARACTER*80 X
         WRITE(*,'(A)') X
         OKPLT = X
         RETURN
         END
 C
         CHARACTER*80 OKPLT
         CHARACTER*80 DOIT
         CHARACTER*10 CHARVAR
         CHARVAR = '1234567890'
         DOIT = 'TEXT'// CHARVAR // ' TEXT2'
         WRITE (*,'(A)') DOIT
         DOIT = OKPLT('TEXT'// CHARVAR // ' TEXT2')
 C       The above line does not pass the concatenation results
 C       correctly.
         WRITE (*,'(A)') DOIT
         END

    This is a known problem in Version 4.01.
    Microsoft is researching this problem and will post new information
 as it becomes available.


 225. Loop Optimization

 Product Version(s): 4.00
 Operating System:   MS-DOS
 Flags: ENDUSER | TAR65661 buglist4.01
 Last Modified:  1-JUN-1988    ArticleIdent: Q25161

 Problem:
    The following code will generate an incorrect result when loop
 optimization is on:

           n=3
           nseq=1
           ns=21
           do 80 k=1,ns
           ni=k
           nbit=0
   1       nbit=nbit+mod(ni,2)
           ni=ni/2
           if(ni.gt.0) go to 1
           if(nbit.ne.n) go to 80
           nseq=nseq+1
   80      continue
           write(*,*) nseq
           end

    In the above example, "nseq" should be 7; instead, it returns 22.

 Response:
    This is a known problem in Version 4.01.
    The only workaround is to turn off loop optimization by recompiling
 the source with /Odct option.
    Microsoft is researching the problem and will post new information
 as it becomes available.


 226. Problem with Function INT and Optimization

 Product Version(s): 4.01
 Operating System:   MS-DOS
 Flags: ENDUSER | TAR65841 buglist4.01
 Last Modified:  1-JUN-1988    ArticleIdent: Q25380

    The intrinsic function INT does not work correctly if optimization
 is on; it rounds the number off instead of truncating it. The
 following is a sample code:

       integer*4 i
       flt = 128.67
       i=nint(flt)
       write(*,*) 'flt,i,nint(flt),int(flt):',flt,i,nint(flt),int(flt)
       end

    With the default optimization, the output is the following:

    flt,i,nint(flt),int(flt):    128.670000     129     129   129

    The correct output should be:

    flt,i,nint(flt),int(flt):    128.670000     129     129   128

    This is a known problem with Version 4.01.
    Microsoft is researching this problem and will post new information
 as it becomes available.
    The workaround is to turn off optimization by recompiling the
 source with /Od option.


 227. Internal Compiler Error: grammar.c, Line 91 and FORTRAN 4.01

 Product Version(s): 4.01
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist4.01 fixlist4.10
 Last Modified: 24-JUL-1990    ArticleIdent: Q25429

 Problem:
    The following program generates "fatal error F1001: Internal
 Compiler Error in file grammar.c, line 91":

         PROGRAM GRAMMAR
         DIMENSION ITIMES(11)
         DIMENSION ITOT(11,50),IBEG(11,50)
         COMMON/A2/IHRS,NPAR
         DATA NTIMES/0/
         DO 30 I=1,NPAR
         IF(ITOT(I,ITIMES(I)).LT.IHRS)THEN
            IBEG(I,ITIMES(I))=0
         ELSE
            ITIMES(I)=ITIMES(I)+1
         ENDIF
  30     IF(ITIMES(I).GT.NTIMES)NTIMES=ITIMES(I)
         RETURN
         END

 Response:
    Microsoft has confirmed this to be a problem with Version 4.01 of
 the FORTRAN compiler. This problem was corrected in Version 4.10.
    The workaround is to either turn off loop optimization with the /Od
 or /Odct, or to ensure floating point variable storage with the /Op
 switch.


 228. Repeated Use of BACKSPACE Causes Run-Time Error F6501

 Product Version(s): 4.01
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist4.01
 Last Modified:  1-JUN-1988    ArticleIdent: Q25432

 Problem:
    The following program and data file cause run-time error F6501 "End
 of File Encountered":

    $storage:2
    $debug
            character*80 rtnstr
            integer fun/3/
            open(fun,file='test.dat')
            read(fun,1000) rtnstr
    1000  format(A)
            backspace fun
            backspace fun
            close(fun)
            end

 Response:
    The error seems to be caused by repeated use of BACKSPACE when the
 file pointer already is positioned near the beginning of the file. The
 data file TEST.DAT contains one integer number and no carriage return
 line feed.
    The workaround is to set the blocksize to a larger value, as in the
 following open statement:

    open(fun,file='test.dat',blocksize=2048)

    Microsoft is researching this problem and will post new information
 as it becomes available.


 229. Problem Evaluating Expressions with Complex Variables

 Product Version(s): 4.00 4.01
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist4.00 buglist4.01
 Last Modified: 20-OCT-1988    ArticleIdent: Q25452

 Problem:

 The following program illustrates a problem with the Versions 4.00 and
 4.01 FORTRAN compiler regarding the evaluation of complex expressions:

        program cmplx
        complex*8 x, z

        z=(0., 1.)
        write(*,'(1x,''z=             '', 2(1x, f10.3))') z
        x = 1.-z
        write(*,'(1x,''x=1.-z         '',2(1x,f10.3))') x
        x = 1.+(-z)
        write(*,'(1x,''x=1.+(-z)      '',2(1x,f10.3))') x
        x = 1.+(-1.)*z
        write(*,'(1x,''x=1.+(-1.)*z   '',2(1x,f10.3))') x
        x = 1.+(0.-1.)*z
        write(*,'(1x,''x=1.+(0.-1.)*z '',2(1x,f10.3))') x
        x = 1.-z
        write(*,'(1x,''x=1.-z         '',2(1x,f10.3))') x
        end

 The program was compiled using the default compiler options; however,
 the option selected does not appear to impact the performance of this
 program. Also, the use of complex*16 produces the same result.

 The output under FORTRAN Version 4.00 is the following:

    z=                    .000      1.000
    x=1.-z               1.000      1.000
    x=1.+(-z)            1.000     -1.000
    x=1.+(-1.)*z         1.000       .000
    x=1.+(0.-1.)*z       1.000       .000
    x=1.-z               1.000      1.000

 The output under FORTRAN Version 4.01 is the following:

    z=                    .000      1.000
    x=1.-z               1.000     -1.000
    x=1.+(-z)            1.000     -1.000
    x=1.+(-1.)*z         1.000       .000
    x=1.+(0.-1.)*z       1.000       .000
    x=1.-z               1.000     -1.000

 The correct result is the following:

    z=                    .000      1.000
    x=1.-z               1.000     -1.000
    x=1.+(-z)            1.000     -1.000
    x=1.+(-1.)*z         1.000     -1.000
    x=1.+(0.-1.)*z       1.000     -1.000
    x=1.-z               1.000     -1.000

 Response:

 Microsoft has confirmed this to be a problem in Versions 4.00 and
 4.01. We are researching this problem and will post new information as
 it becomes available.


 230. Internal Compiler Error: trees.c, Line 1165

 Product Version(s): 4.00 4.01
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist4.00 buglist4.01
 Last Modified:  1-JUN-1988    ArticleIdent: Q25465

    The following program:

    program trees
    character ch(20)
    ch() = 'a'
    end

 causes the compiler to generate the following error message:

  trees.for(3) : fatal error F1001: Internal Compiler Error
            (compiler file '../trees.c', line 1165)
            Contact Microsoft Technical Support

    This program was compiled using the default compiler options.
 However, when options are selected, they do not appear to affect the
 error.
    This is a known problem in Versions 4.00 and 4.01.
    Microsoft is researching this problem and will post new information
 as it becomes available.
    The only workaround is to include an array index on Line 3 of the
 example.


 231. FORTRAN 4.10 README.DOC: OS/2 Demonstration Program

 Product Version(s): 4.10    | 4.10
 Operating System:   MS-DOS  | OS/2
 Flags: PSSONLY | ENDUSER Doscalls API system
 Last Modified: 30-OCT-1990    ArticleIdent: Q28796

    The following information is from the FORTRAN Version 4.10
 README.DOC file:

 OS/2 Demonstration Program
    The program SORTDEMO.FOR on the distribution disks contains
 examples of how to make OS/2 calls from a FORTRAN program. See the
 PACKING.LST file for the location of the program.


 232. FORTRAN 4.10 README.DOC: Common Problems with SETUP

 Product Version(s): 4.10    | 4.10
 Operating System:   MS-DOS  | OS/2
 Flags: PSSONLY | ENDUSER
 Last Modified: 30-OCT-1990    ArticleIdent: Q28797

    The following information is from the FORTRAN Version 4.10
 README.DOC File:

 Common Problems with SETUP
    When run to create a library, SETUP may quit with an error message
 telling you that the LIB program cannot be found or run. Doing one or
 more of the following steps, in turn, should resolve the problem:

    1. Ensure that the LIB.EXE program is in one of the directories in
 the path. If necessary, modify your path and rerun SETUP.
    2. Remove all terminate and stay resident (TSR) programs from
 memory and try SETUP again.
    3. Reduce your system's environment space as much as possible and
 rerun SETUP.


 233. FORTRAN 4.10 README.DOC: Floating-Point Operations

 Product Version(s): 4.10    | 4.10
 Operating System:   MS-DOS  | OS/2
 Flags: PSSONLY | ENDUSER
 Last Modified: 30-OCT-1990    ArticleIdent: Q28798

    The following information is from the FORTRAN Version 4.10
 README.DOC file:

 Floating-Point Operations under PC-DOS 3.20
    If you are running IBM(R) Personal Computer DOS (PC-DOS) 3.20 and
 trapping floating-point exceptions in your program, you may find it
 necessary to patch PC-DOS 3.20 to get proper operation when
 floating-point exceptions occur. Please refer to the file named
 README.DOC in the \PATCH subdirectory on the Setup distribution disk
 for instructions on making this patch.

 Floating-Point Operations under MS-DOS 3.20
    This information is important only if your system has ALL of the
 following characteristics:

    1. You use MS-DOS Version 3.20.
    2. You boot from a hard disk drive.
    3. Your system has a math coprocessor (for instance, an 8087 chip).
    4. You run programs that use floating-point math.

    For systems that satisfy all of the preceding conditions, you may
 be able to eliminate floating-point math problems by installing a
 small patch in DOS. If you are not sure whether you need the patch,
 perform the following steps:

    1. Copy the program PATCH87.EXE (included in this release on Disk
 1) 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, since 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 this 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 it can be performed 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.

    NOTE: The floating-point problem has been eliminated in versions of
 MS-DOS higher than 3.20. This includes MS-DOS Versions 3.21 and 3.30.
    If you performed the preceding test and determined that you should
 install the DOS patch on your system, perform the following steps:

    1. Format a blank floppy disk. (Do NOT use the /s formatting option
 to transfer system files to the disk.)
    2. Use the SYS command to copy IO.SYS and MSDOS.SYS from the root
 directory of your hard disk to the new floppy disk. For instance, if
 you boot from Drive C:, you would enter the following commands:

             C:
             SYS A:

    3. Use the COPY command to copy COMMAND.COM and SYS.COM to the same
 floppy disk.
    4. Use the COPY command to copy the program PATCH87.EXE (included
 in this release) to the same floppy disk.
    5. Change the current drive and directory to the floppy disk, by
 entering the following command:

             A:

    6. Install the DOS patch by entering the following command:

             PATCH87 /F

    WARNING: If you experience any disk errors during steps 2 through
 6, do not proceed with step 7. Reboot from your hard disk and repeat
 the entire process.
    7. If you have not experienced any errors, use the SYS command to
 transfer the files IO.SYS and MSDOS.SYS from the floppy disk back to
 your hard disk. For instance, if the boot directory of your system is
 the root directory of Drive C:, you would enter the following command
 at the DOS prompt:

             A:
             SYS C:

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


 234. FORTRAN 4.10 README.DOC: New Versions of LINK.EXE and LIB.EXE

 Product Version(s): 4.10   | 4.10
 Operating System:   MS-DOS | OS/2
 Flags: PSSONLY | ENDUSER
 Last Modified: 30-OCT-1990    ArticleIdent: Q28799

    The following information is from the FORTRAN Version 4.10
 README.DOC file:

 GENERAL NOTES
    Version 4.10 of the Microsoft FORTRAN Optimizing Compiler fixes a
 number of errors in Version 4.01.
    This section provides additional information about the compiler,
 how the compiler optimizes programs, and about common problems and
 their solutions.

 New Versions of LINK.EXE and LIB.EXE
    Earlier versions of the linker will not correctly link programs
 compiled with FORTRAN Version 4.10. Use the Segmented-Executable
 linker (LINK.EXE) included on the distribution disks, or a later
 version. You may need to modify the path specified in your
 AUTOEXEC.BAT file to ensure that the correct version of the linker is
 used.
    Also be sure to use the version of the Library Manager, LIB.EXE,
 included on the distribution disks. You may need to modify your path
 to make sure the correct version of LIB is used.


 235. FORTRAN 4.10 README.DOC: Setting Up the Microsoft Editor

 Product Version(s): 4.10   | 4.10
 Operating System:   MS-DOS | OS/2
 Flags: PSSONLY | ENDUSER
 Last Modified: 30-OCT-1990    ArticleIdent: Q28800

    The following information is from the FORTRAN Version 4.10
 README.DOC file:

 Setting Up the Microsoft Editor
    The FORTRAN setup program does not install the Microsoft Editor.
 To install the Microsoft Editor, insert the Microsoft Editor disk and
 run the MSETUP batch file. To use the MSETUP batch file under
 protected-mode OS/2, rename MSETUP.BAT to MSETUP.CMD.
    For more information about the Microsoft Editor, see the Microsoft
 Editor User's Guide and the CVREADME.DOC file on the CodeView for
 MS-DOS disk.


 236. FORTRAN 4.10 README.DOC:Optimizations and End-of-File Checking

 Product Version(s): 4.10   | 4.10
 Operating System:   MS-DOS | OS/2
 Flags: PSSONLY | ENDUSER
 Last Modified: 30-OCT-1990    ArticleIdent: Q28801

    The following information is from the FORTRAN Version 4.10
 README.DOC file:

 Optimizations and End-of-File Checking
    With the default optimizations performed by the compiler, a READ
 statement like

    READ (1,*,END=100) (X(I), I = 1, 10)

 may cause problems because end-of-file checking is performed only when
 the loop is exited, not after each pass through the loop.
    If you encounter similar problems in a program, compile the program
 with the /Od option to disable optimizations.


 237. FORTRAN 4.10 README.DOC: Linking MS FORTRAN and MS C Modules

 Product Version(s): 4.10   | 4.10
 Operating System:   MS-DOS | OS/2
 Flags: PSSONLY | ENDUSER
 Last Modified: 30-OCT-1990    ArticleIdent: Q28802

    The following information is from the FORTRAN Version 4.10
 README.DOC file:

 Linking Microsoft FORTRAN and Microsoft C Modules
    If you use SETUP to create a library that is compatible with
 Microsoft C, then you MUST specify and use the actual Microsoft C
 Version 4.00 library (either LLIBC.LIB or MLIBC.LIB, depending on the
 memory model) when you link with the C-compatible FORTRAN library.


 238. FORTRAN 4.10 README.DOC: Floating-Point Options

 Product Version(s): 4.10    | 4.10
 Operating System:   MS-DOS  | OS/2
 Flags: PSSONLY | ENDUSER
 Last Modified: 30-OCT-1990    ArticleIdent: Q28803

    The following information is from the FORTRAN Version 4.10
 README.DOC file:

 Library Considerations for Floating-Point Options
    See Section 8.3.1 of the Microsoft FORTRAN Compiler User's Guide
 for information about specifying libraries in addition to the default
 library for the floating-point option that you select on the FL
 command line.


 239. FORTRAN 4.10 README.DOC: Internal Compiler Assertions

 Product Version(s): 4.10    | 4.10
 Operating System:   MS-DOS  | OS/2
 Flags: PSSONLY | ENDUSER
 Last Modified: 30-OCT-1990    ArticleIdent: Q28804

    The following information is from the FORTRAN Version 4.10
 README.DOC file:

 Internal Compiler Assertions
    In trying to perform optimizations on extremely complex code, the
 compiler may experience an internal error condition. Sometimes it is
 possible to work around this problem by disabling the optimization
 pass of the compiler with the /Od option.
    In all cases where you experience this type of compiler error,
 please contact Microsoft Corporation so that corrections can be made
 for subsequent releases.


 240. FORTRAN 4.10 README.DOC: Stack Size in OS/2 Programs

 Product Version(s): 4.10    | 4.10
 Operating System:   MS-DOS  | OS/2
 Flags: PSSONLY | ENDUSER
 Last Modified: 30-OCT-1990    ArticleIdent: Q28805

    The following information is from the FORTRAN Version 4.10
 README.DOC file:

 Stack Size in OS/2 Programs
    Any FORTRAN program running in protected-mode should have at least
 2K of free stack space at the beginning of an operating system call.
 Because the FORTRAN program itself uses some of the stack before the
 system call, the default stack size of 2K may not be adequate. You
 should increase the stack size of your program to ensure sufficient
 free stack space for operating system calls. Use the /F driver option
 or the /ST linker option to increase the stack size. A stack size of
 3K to 4K should be sufficient in most cases.
    NOTE: All programs running in protected-mode make operating system
 calls through the run-time system and should use a stack size of 3K to
 4K.


 241. MS-DOS Device Names

 Product Version(s): 3.20
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 12-MAY-1988    ArticleIdent: Q10200

 Question:
    DOS treats file names such as CON and ERR as device names when the
 DOS2FOR library is used.
    Can DOS treat any file name as a device?

 Response:
    The association of the name ERR to the DOS device handle "stderr"
 is done by FORTRAN (i.e., DOS2FOR, not DOS itself).
    There is no FORTRAN command, subroutine, or function to determine
 whether or not a given name is the name of a DOS device. It is
 possible to make this determination in an assembly language subroutine
 by doing the following:

    1. Open a handle using the file name
    2. Perform an IOCTL call on that handle


 242. FORTRAN 4.10 README.DOC: Iteration Counts for DO Loops

 Product Version(s): 4.10   | 4.10
 Operating System:   MS-DOS | OS/2
 Flags: PSSONLY | ENDUSER
 Last Modified: 30-OCT-1990    ArticleIdent: Q28806

    The following information is from the FORTRAN Version 4.10
 README.DOC file:

 Iteration Counts for DO Loops
    As explained in Section 5.3.13 of the Microsoft FORTRAN Optimizing
 Compiler Language Reference, the following formula is used to compute
 the iteration count for a DO loop:

      MAX(INT((stop - start +inc)/inc), 0)

    Note that the iteration count is computed in two-byte precision,
 the default for integers. If the iteration count overflows this
 precision, the results are unpredictable. The following is an example
 of code that causes this problem:

      IMPLICIT INTEGER*2 (A-Z)
      IEND = 32000
      ISTEP = 12000
      DO 10 I=0,IEND,ISTEP
        WRITE (*,*) 'I=',I
 10   CONTINUE
      END


 243. .LST Files and Parameter Statement

 Product Version(s): 3.20
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 12-MAY-1988    ArticleIdent: Q10376

 Problem:
    .LST files do not list the data type of identifiers used in
 parameter definitions.

 Response:
    This problem was corrected in Version 3.30.


 244. FORTRAN 4.10 README.DOC: Path Specifications for the Linker

 Product Version(s): 4.10   | 4.10
 Operating System:   MS-DOS | OS/2
 Flags: PSSONLY | ENDUSER
 Last Modified: 30-OCT-1990    ArticleIdent: Q28807

    The following information is from the FORTRAN Version 4.10
 README.DOC file:

 Path Specifications for the Linker
    Please make sure that the linker that comes with the Microsoft
 FORTRAN Optimizing Compiler Version 4.10 is the first linker in your
 path specification.


 245. Source File Named "ERR.FOR"

 Product Version(s): 3.20
 Operating System:   MS-DOS
 Flags: enduser |
 Last Modified:  9-MAR-1988    ArticleIdent: Q10411

 Problem:
    A source file with the name "ERR.FOR" hangs the first pass of the
 compiler (FOR1).

 Response:
    This is not a problem with the compiler but is a restriction that
 has been eliminated in Version 4.00.
    This file name does not hang the computer; rather, the computer is
 waiting for input from the keyboard. Issuing a CONTROL-C will return
 you to the DOS prompt.
    Both the FORTRAN compiler and the run-time library associate the
 name "ERR" with the MS-DOS standard error device handle. When you
 issue the command "FOR1 ERR;", the FORTRAN compiler expects source
 code from the keyboard rather than a file named "ERR.FOR".


 246. FORTRAN 4.10 README.DOC: Invariant Expressions in DO Loops

 Product Version(s): 4.10   | 4.10
 Operating System:   MS-DOS | OS/2
 Flags: PSSONLY | ENDUSER
 Last Modified: 30-OCT-1990    ArticleIdent: Q28808

    The following information is from the FORTRAN Version 4.10
 README.DOC file:

 Invariant Expressions in DO Loops
    Calculations in DO loops may involve variables whose values do not
 change within the loop. Such calculations should be performed outside
 of the loop. Performing calculations outside the loop saves time and
 allows you, rather than the compiler, to choose which invariant
 expressions are removed.
    The following sample program includes a DO loop that may cause
 program failure:

             REAL NUMER
             DIMENSION ARRAY(100)
             DO 10 I=1,100
               IF (DENOM .NE. 0) ARRAY(I) = ARRAY(I)+NUMER/DENOM
      10     CONTINUE
             END

    The compiler knows that NUMER/DENOM does not change within the
 loop, so it calculates NUMER/DENOM only once: before the start of the
 loop and before the IF statement within the loop can check for
 division by zero. You could rewrite the program as shown below to
 avoid this problem:

            REAL NUMER
            DIMENSION ARRAY(100)
            TEMP = 0.0
            IF (DENOM .NE. 0) TEMP = NUMER/DENOM
            DO 10 I=1,100
              ARRAY(I) = ARRAY(I)+TEMP
      10    CONTINUE
            END


 247. FORTRAN 4.10 README.DOC: Input/Output System

 Product Version(s): 4.10   | 4.10
 Operating System:   MS-DOS | OS/2
 Flags: PSSONLY | ENDUSER
 Last Modified: 30-OCT-1990    ArticleIdent: Q28809

    The following information is from the FORTRAN Version 4.10
 README.DOC file:

 NEW AND CHANGED FEATURES
    The following notes describe important new and changed features in
 the Microsoft FORTRAN Optimizing Compiler and the software provided
 with the compiler.

 Input/Output System -- Limits on Left Tabbing
    Left tabbing is legal within records written to devices. However,
 if the record that is written is longer than the buffer associated
 with the device, you cannot left tab to a position corresponding to
 the "previous" buffer.
    For example, the buffer associated with the console is 132 bytes
 long. If a record of 140 bytes is written to the console, left tabbing
 is allowed for only eight bytes, since the first 132 bytes of the
 record have been sent to the device and are no longer accessible.

 IOCHECK and Run-Time Error Numbers
    If the IOSTAT option is set and an error or end-of-file occurs at
 run time, the "iocheck" variable is set to the number of the run-time
 error. For example, if the following READ statement encounters an
 end-of-file

    READ(1,'(I5)',IOSTAT=IER) JUNK

 the IER variable is set to 6501, the number of the run-time error for
 an end-of-file condition.

 The END= Option with Direct-Access Files
    The END= I/O option can be specified along with the REC= I/O
 option in I/O statements.


 248. FORTRAN 4.10 README.DOC: New and Changed Compiler Features

 Product Version(s): 4.10    | 4.10
 Operating System:   MS-DOS  | OS/2
 Flags: PSSONLY | ENDUSER
 Last Modified: 30-OCT-1990    ArticleIdent: Q28810

    The following information is from the FORTRAN Version 4.10
 README.DOC file:

 Compiler -- Underscores (_) in Variable Names
    The underscore (_) can be used in variable names, as long as it is
 not the first character of a name.

 Character-Assignment Statements
    In a character-assignment statement, the variable to the left of
 the equal sign (that is, the variable having a value assigned to it)
 cannot appear as part of the character expression to the right of the
 equal sign (that is, the expression being assigned). For example, the
 following statement gives undefined results:

       var = varp // var

 The FUNCTION Statement
    In FUNCTION statements, the length specifier for the function type
 may follow the function name. For example, the following two
 declarations are equivalent:

       INTEGER*4 FUNCTION X(A)

       INTEGER FUNCTION X*4(A)

 Limits on Assigned-GOTO Statements
    The compiler limit on assigned-GOTO statements has been raised from
 64 per subroutine to 256 per subroutine.

 The PAUSE Statement
    If a string argument follows the PAUSE statement, then on output
 the argument appears without the "Pause" and the pause message. If a
 digit argument follows the PAUSE statement, then on output the "Pause"
 appears, followed by the digit. The following examples illustrate
 PAUSE statements and the messages that the statements display:

 C   EXAMPLE 1:  PAUSE STATEMENT WITH NO ARGUMENT

       PAUSE

 Pause - Please enter a blank line (to continue) or a DOS command.

 C   EXAMPLE 2:  PAUSE STATEMENT WITH STRING ARGUMENT

       PAUSE 'hit return to continue'

 hit return to continue

 C   EXAMPLE 3:  PAUSE STATEMENT WITH DIGIT ARGUMENT

       PAUSE 1

 Pause - 1


 249. Colon Required between the $NOTLARGE and Following Identifiers

 Product Version(s): 3.20
 Operating System:   MS-DOS
 Flags: ENDUSER | docerr
 Last Modified: 19-SEP-1988    ArticleIdent: Q10538

 Problem:

 The following code sample generates the error message "Error 824 --
 $large already set":

 $LARGE $NOTLARGE A,B
    DIMENSION A(10),B(10)
    END

 Response:

 Contrary to Page 73 of the "Microsoft FORTRAN Compiler User's Guide,"
 a colon is required between the $NOTLARGE and the identifiers that
 follow it. When the colon is missing, the identifiers are ignored and
 an error is generated. The above code should be changed to the
 following:

 $LARGE $NOTLARGE: A,B
    DIMENSION A(10),B(10)
    END


 250. Cannot Detect End of File

 Product Version(s): 3.20
 Operating System:   MS-DOS
 Flags: ENDUSER | docerr
 Last Modified:  7-SEP-1988    ArticleIdent: Q10539

 Problem:

 I am unable to detect end-of-file for direct access files.

 Response:

 Page 81 of the "Microsoft FORTRAN Compiler Reference" manual
 incorrectly states ENDFILE works when linked with the DOS2FOR library.

 The file-handling methods under DOS Versions 1.x cannot work with
 direct-access files. However, you can detect end-of-file for direct
 access files if you link with the DOS2FOR library that uses DOS
 Versions 2.x file-handling methods.


 251. FORTRAN 4.10 README.DOC: OS/2 Calls from FORTRAN

 Product Version(s): 4.10    | 4.10
 Operating System:   MS-DOS | OS/2
 Flags: PSSONLY | ENDUSER Doscalls API system
 Last Modified: 30-OCT-1990    ArticleIdent: Q28811

    The following information is from the FORTRAN Version 4.10
 README.DOC file:

 OS/2 Calls from FORTRAN
    OS/2 functions can be called from FORTRAN as integer functions.
 The fragment below shows how to call the OS/2 function VioGetMode (the
 sample program SORTDEMO.FOR contains numerous examples of OS/2 calls):

 $NOTRUNCATE
         INTERFACE TO INTEGER*2 FUNCTION VioGetMode
      +  [ALIAS:'VIOGETMODE']
      +  (MODE, VioHandle [VALUE])
         INTEGER*2 MODE(6), VioHandle
         END

         IMPLICIT INTEGER*2 (A-Z)
         DIMENSION MODE(6)
         .
         .
         MODE(1)=12
         RetVal=VioGetMode(MODE,0)
         MAXCOLOR=2**ISHL(MODE(2),-8)
         .
         .
         END

 Declaring OS/2 Functions
    To call an OS/2 function, you must first declare the function using
 an INTERFACE statement. The INTERFACE statement declares the function
 type and the number and type of the function's arguments. All OS/2
 functions are declared as INTEGER*2 functions because they return a
 single two-byte value (see below).
    Because OS/2 function names are usually longer than the normal
 FORTRAN limit of six characters, you must use the ALIAS attribute, the
 $NOTRUNCATE metacommand, or both. If you change the OS/2 function name
 to fit in six characters, you must use the ALIAS attribute to make the
 link between your program's name for the function and its actual OS/2
 name. If you use the $NOTRUNCATE metacommand, you may omit the ALIAS
 attribute because $NOTRUNCATE ensures that FORTRAN accepts up to 31
 characters for a variable or procedure name.
    To determine the number and type of the OS/2 function's arguments,
 look up the function in the MS OS/2 Programmer's Reference and use the
 tables on pages 280-293 in the Microsoft FORTRAN Optimizing Compiler
 User's Guide to find the FORTRAN data type corresponding to the C data
 type in the function call. Notice that you must use the VALUE
 attribute in the INTERFACE statement for any OS/2 function argument
 that is not a pointer.
    Some OS/2 function calls take the address of a structure as an
 argument. Because FORTRAN does not have a structure or record data
 type, you must use an integer array to simulate the structure. In the
 example above, the VioGetMode function uses a twelve-byte structure,
 so MODE is declared as a six-element array of two-byte words. MODE
 could also have been declared as a twelve-element array of INTEGER*1.
    If you emulate a structure using an INTEGER*1 array and the
 structure contains word fields, or you use an INTEGER*2 array and the
 structure contains byte fields, your program will need to do some
 extra work to access the fields. You can use bit-manipulation
 functions or equivalenced arrays to get at byte fields in word arrays
 or word fields in byte arrays.
    See pp. 90-92 in the Microsoft FORTRAN Optimizing Compiler Language
 Reference for information about FORTRAN's bit-manipulation functions.
 Notice that if you use an INTEGER*1 array and the structure contains
 word fields, you'll use the bit functions to combine array elements.
 Similarly, if you use an INTEGER*2 array and the structure contains
 byte fields, you'll need to use the bit functions to manipulate the
 byte fields.
    Because bytes in a two-byte integer are stored in reverse order,
 you must be careful to select the correct byte when breaking down
 two-byte integer values.  For example, the twelve-byte structure used
 with VioGetMode begins with a word value followed by two one byte
 values: type and color. In the example above, the two one-byte fields
 are treated as a single integer, so color winds up in the high-order
 byte and type is the low-order byte. So, to get the value of color
 (the high-order byte of MODE(2)), you must shift MODE(2) right by
 eight bit positions.
    You can avoid doing bit manipulation by using the EQUIVALENCE
 statement. The following segment shows the fragment above rewritten
 to avoid bit manipulation:

 $NOTRUNCATE
         INTERFACE TO INTEGER*2 FUNCTION VioGetMode
      +  [ALIAS:'VIOGETMODE']
      +  (MODE, VioHandle [VALUE])
         INTEGER*2 MODE(6), VioHandle
         END

         IMPLICIT INTEGER*2 (A-Z)
         DIMENSION MODE(6)
         INTEGER*1 BMODE(2),Color,Type
         EQUIVALENCE (BMODE(1),MODE(2)),(BMODE(1),Type),(BMODE(2),Color)
         .
         .
         MODE(1)=12
         RETVAL=VioGetMode(MODE,0)
         MaxColor=2**Color
         .
         .
         END

    The EQUIVALENCE statement equates the start of the two-element
 INTEGER*1 array, BMODE, to the two one-byte fields in the MODE
 structure. The statement then equates two INTEGER*1 variables to the
 individual byte fields. Notice that when you use an EQUIVALENCE
 statement this way, you do not have to worry about reversed bytes.
    NOTE: OS/2 calls assume that all arguments passed by reference are
 passed as far references. Thus, if you use medium memory model (which
 uses near references), you must use the FAR attribute with any
 arguments that are passed by reference.

 Return Values
    The value returned by an OS/2 function indicates whether or not
 there was an error. A return value of zero indicates there was no
 error; any other value indicates an error. See the Microsoft OS/2
 Programmer's Reference for information about specific error values.

 Thread Restrictions
    Because FORTRAN library routines are not reentrant, FORTRAN
 routines that use any of the OS/2 functions involving threads or
 requiring reentrancy cannot use FORTRAN library routines. The OS/2
 functions that use multiple threads or require reentrancy include the
 following:

 DOSCREATETHREAD
 DOSRESUMETHREAD
 DOSSUSPENDTHREAD
 DOSSETSIGHANDLER
 DOSSETVEC
 DOSMONOPEN
 DOSMONCLOSE
 DOSMONREAD
 DOSMONWRITE
 DOSMONREG

    You may be able to write routines using these OS/2 functions and
 FORTRAN library routines if your program provides a way for each
 routine to test whether or not another routine is using the library
 routines. Or, you may want to write your own reentrant library
 routines. (This is an advanced technique that Microsoft does not
 support.)


 252. FORTRAN 4.10 README.DOC: Corrections to Documentation

 Product Version(s): 4.10   | 4.10
 Operating System:   MS-DOS | OS/2
 Flags: PSSONLY | ENDUSER
 Last Modified: 30-OCT-1990    ArticleIdent: Q28812

    The following information is from the FORTRAN Version 4.10
 README.DOC file:

 CORRECTIONS TO DOCUMENTATION -- Version 4.10 Update

 LIBBUILD under Protected-Mode OS/2
    To use the LIBBUILD.BAT batch file under protected-mode OS/2,
 change the file's name to LIBBUILD.CMD.

 Additional Error Messages
    There are two new command line messages:

    Number  Message                      Description

    D2025   missing argument             A required argument was omitted
                                         from the option. Check the syntax
                                         of the option. This is an error
                                         message.

    D4019   string too long - truncated  A string of more than 40 characters
            to 40 characters             was specified for one of the followin
                                         switches: /NM, /NT, /St, or /Ss.
                                         The string is truncated to 40
                                         characters, and FL continues. This
                                         message is a warning.

    There is one new compiler warning message:

    F4186    string too long - truncated  A string of more than 40 characters
             to 40 characters             was used in a $TITLE or $SUBTITLE
                                          metacommand. The string is truncated
                                          to 40 characters.

 User's Guide -- Defining Macros for MAKE
    Section 6.7.1 states that macro definitions that include white
 space should be enclosed in double quotes. This statement is true only
 for macros defined on the MAKE command line. Macros with white space
 in MAKE description files should not be enclosed in double quotes.

 Quick Reference Guide
    In the Microsoft FORTRAN Optimizing Compiler Quick Reference Guide,
 the /Tf option of the FL command is misspelled as "/TF".


 253. FORTRAN 4.10 CVREADME.DOC: Mouse Driver

 Product Version(s): 4.10   | 4.10
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified: 27-APR-1988    ArticleIdent: Q28815

    The following information is from the FORTRAN Version 4.10
 CVREADME.DOC file:

 CVREADME.DOC -- (C) Copyright Microsoft Corporation, 1987, 1988
 Microsoft(R) FORTRAN Optimizing Compiler Version 4.10

 Notes on CodeView and Utilities -- The Mouse Driver
    If you will be using the Microsoft Mouse with the Microsoft
 CodeView debugger you must have Version 6.01 or later of the Microsoft
 Mouse. If you do not, use the version of the MOUSE.COM driver provided
 in this package. Copy MOUSE.COM to the appropriate mouse directory.
 When you are ready to use the mouse, type

         mouse

 at the DOS command level. If you want to install the mouse driver
 automatically every time you reboot, insert the "mouse" command in
 your AUTOEXEC.BAT file.
    Note that in earlier releases of Microsoft C, both the MOUSE.SYS
 and the MOUSE.COM driver were provided. If you have been using an
 earlier version of the MOUSE.SYS driver, delete the following line
 from your CONFIG.SYS file:

         device=\<directory>\mouse.sys

 where <directory> is the directory where the earlier mouse driver
 resides.


 254. FORTRAN 4.10 CVREADME.DOC: New Command-Line Option

 Product Version(s): 4.10   | 4.10
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified: 27-APR-1988    ArticleIdent: Q28816

    The following information is from the FORTRAN Version 4.10
 CVREADME.DOC file:

 Microsoft CodeView(R) Debugger -- New Command-Line Option
    If you have an IBM Personal System/2, then you can use the /50
 command-line option to start the CodeView debugger in 50-line mode.
 Note that you must be in 25-line mode to effectively use either the
 /43 or /50 command-line option.


 255. FORTRAN 4.10 CVREADME.DOC: CONFIG.SYS Setting for CVP

 Product Version(s): 4.10    | 4.10
 Operating System:   MS-DOS  | OS/2
 Flags: ENDUSER |
 Last Modified: 27-APR-1988    ArticleIdent: Q28817

    The following information is from the FORTRAN Version 4.10
 CVREADME.DOC file:

 CONFIG.SYS Setting for CVP
    To run the protected-mode CodeView debugger (CVP.EXE), you must
 have the following line in your CONFIG.SYS file:

    IOPL=YES


 256. Complex Division

 Product Version(s): 3.2
 Operating System:   MS-DOS
 Flags: ENDUSER | TAR02493 buglist3.20 fixlist3.30
 Last Modified:  8-MAR-1988    ArticleIdent: Q10633

 Problem:
    Contrary to the documentation, the negative range of double
 precision complex numbers is 1X10**-154. Attempts to use greater
 negative numbers results in a real math overflow at runtime.

 Response:
    Microsoft confirmed this to be a problem in Version 3.20 of the
 FORTRAN compiler.
   The problem was corrected in Version 3.30.


 257. FORTRAN 4.10 CVREADME.DOC: CodeView Demonstration

 Product Version(s): 4.10    | 4.10
 Operating System:   MS-DOS  | OS/2
 Flags: ENDUSER |
 Last Modified: 27-APR-1988    ArticleIdent: Q28818

    The following information is from the FORTRAN Version 4.10
 CVREADME.DOC file:

 Microsoft CodeView(R) Debugger Demonstration
    The demonstration runs only under MS-DOS or real-mode OS/2. You
 must compile the program STATS.FOR before you can run the CodeView
 demonstration. Compile the program using the following command and
 place the EXE file in the same directory as the other demonstration
 files:

    FL /AM /FPc /Zi /Od STATS.FOR


 258. FORTRAN 4.10 CVREADME.DOC: IMAG and AIMAG

 Product Version(s): 4.10    | 4.10
 Operating System:   MS-DOS  | OS/2
 Flags: ENDUSER |
 Last Modified: 27-APR-1988    ArticleIdent: Q28819

    The following information is from the FORTRAN Version 4.10
 CVREADME.DOC file:

 IMAG and AIMAG Intrinsic Functions
    The Microsoft CodeView(R) debugger considers the IMAG and AIMAG
 functions to be synonymous (it extracts the imaginary part of the
 complex number).

 Using the 7 Command in Protected Mode
    If you are using OS/2 protected mode and have a math coprocessor,
 then you need to use a patch before you can use the CVP 7 command. To
 apply the patch, use the OS2PATCH.EXE and PTRACE87.PAT files that come
 on the same disk that CVP.EXE is on. You also need to locate the
 PATCH.EXE file that comes with OS/2 and make sure that this file is in
 a directory listed in your PATH environment variable. Then follow
 these steps:

    1. Change the current drive and directory to the root directory of
 the boot disk. (If the boot disk is a floppy, make sure it is inserted
 in the drive you used to boot from.)
    2. Give the following command line at the DOS prompt:

    OS2PATCH /A PTRACE87.PAT

    Note that you may need to give the complete path names for the
 OS2PATCH.EXE and for the PTRACE87.PAT file. You do not need to give a
 path name for the OS2PATCH.EXE file if you have placed this file in a
 directory listed in your PATH environment variable.


 259. FORTRAN 4.10 CVREADME.DOC: Compatibility Box

 Product Version(s): 4.10    | 4.10
 Operating System:   MS-DOS  | OS/2
 Flags: ENDUSER |
 Last Modified: 27-APR-1988    ArticleIdent: Q28820

    The following information is from the FORTRAN Version 4.10
 CVREADME.DOC file:

 Using the Real-Mode Debugger in the Compatibility Box
    When running the real-mode CodeView debugger in the DOS 3.x
 compatibility box, start the debugger with the /S command-line option.
 Otherwise, the mouse pointer will not appear.


 260. FORTRAN 4.10 CVREADME.DOC: Codeview with BIND

 Product Version(s): 4.10   | 4.10
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified: 27-APR-1988    ArticleIdent: Q28821

    The following information is from the FORTRAN Version 4.10
 CVREADME.DOC file:

 Using the CodeView Debugger with BIND
    The real-mode CodeView debugger cannot debug bound (dual-mode)
 applications. However, the protected-mode CodeView debugger, CVP, can
 debug bound applications.


 261. FORTRAN 4.10 CVREADME.DOC: BASIC Programs with CodeView

 Product Version(s): 4.10    | 4.10
 Operating System:   MS-DOS  | OS/2
 Flags: ENDUSER |
 Last Modified: 27-APR-1988    ArticleIdent: Q28822

    The following information is from the FORTRAN Version 4.10
 CVREADME.DOC file:

 Compiling BASIC Programs for CodeView Debugger
    To compile BASIC programs for use with the CodeView debugger,
 specify the /Zi option rather than the /D option.

 Expression Evaluator for BASIC Programs
    In the BASIC expression evaluator, "+" is not supported for string
 concatenation.


 262. Problems Reading an Array in Version 3.20

 Product Version(s): 3.20
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist3.20 fixlist3.30
 Last Modified:  7-OCT-1988    ArticleIdent: Q10659

 Problem:

 Array reads that read the entire array do not function correctly if
 the array crosses a 64K boundary in a particular way. In the program
 below, support "array" is more than 64K in length, and "barray" is
 equivalenced to array so that barray crosses the 64K boundary in
 array. Reading barray with READ() (barray(i),i=1,dim) works properly,
 but READ()barray fails.

 The following is an example:

         integer*4 array(20000)
         integer*4 barray(2000)
         equivalence(array(16001),barray)
 c
 c
         write(*,*)' writing data'
         open(6,file='data',status='new',form='unformatted')
         write(6)(i,i=1,2000)
 c
 c
         write(*,*)' reading data'
         rewind(6)
         read(6)barray
 c
         ierr=0
         do 10 i=1,2000
         if (barray(i).eq.i) goto 10
         write(*,*)i,barray(i)
         ierr=ierr+1
         if (ierr.eq.10) goto 11
    10   continue
    11   write(*,*)' done checking implicit read'
 c
 c
         write(*,*)' reading data'
         rewind(6)
         read(6)(barray(i),i=1,2000)
 c
         ierr=0
         do 20 i=1,2000
         if (barray(i).eq.i) goto 20
         write(*,*)i,barray(i)
    20   continue
         write(*,*)' done checking explicit read'
         end

 Response:

 The reported behavior was due to an arithmetic overflow in the huge
 array I/O routines.

 Microsoft has confirmed this to be a problem in Version 3.20. This
 problem was corrected in Version 3.30.


 263. FORTRAN 4.10 CVREADME.DOC: Error Message

 Product Version(s): 4.10    | 4.10
 Operating System:   MS-DOS  | OS/2
 Flags: ENDUSER |
 Last Modified: 27-APR-1988    ArticleIdent: Q28823

    The following information is from the FORTRAN Version 4.10
 CVREADME.DOC file:

 Error Messages
    The error message "? cannot display" indicates that the Display
 Expression command (?) has been passed a valid symbol that it cannot
 display. In previous versions of the debugger, structures could not be
 displayed. With current version of the debugger, only the enums type
 cannot be displayed.
    The error message "Expression not a memory address" occurs when the
 Tracepoint command is given without a symbol that evaluates to a
 single memory address. For example, the commands "TP?1" and "TP?a+b"
 each produce this error message. The proper way to put a tracepoint
 on the word at address 1 is with the command "TPW 1".
    The error message "Function call before 'main'" occurs when you
 attempt to evaluate a program-defined function before you have entered
 the main function. Execute to at least to the beginning of the main
 function before attempting to evaluate program-defined functions.
    The error message "Bad emulator info" occurs when CodeView cannot
 read data from the floating-point emulator.
    The error message "Floating point not loaded" has a special meaning
 for CVP (in addition to the explanation given in the CodeView and
 Utilities manual). Each thread has its own floating-point emulator.
 This message is issued when the current thread has not initialized its
 own emulator.


 264. Internal Compiler Error: getattrib.c 1.41, Line 170

 Product Version(s): 4.00 4.01 4.10
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist4.00 buglist4.01 buglist4.10 fixlist5.00
 Last Modified:  6-NOV-1989    ArticleIdent: Q29588

 An incorrectly written program causes the following error message to
 appear:

    fatal error F1001:  Internal Compiler Error
    (compiler file '@(#)getattrib.c:1.41', line 170)
    Contact Microsoft Technical Support

 The following program causes this error:

         SUBROUTINE SUB1(X)
         COMMON Y
         RETURN
         ENTRY SUB2(Y)
         RETURN
         END

 This problem can be avoided by changing the first line to the
 following:

         SUBROUTINE SUB1

 This is a known problem in Versions 4.00, 4.01, and 4.10. This
 problem was corrected in Version 5.00 under MS-DOS. However, the
 compiler gives a general protection violation in OS/2.


 265. Incorrect Integer Arithmetic with /Ot Optimization

 Product Version(s): 4.00 4.01 4.10
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist4.00 buglist4.01 buglist4.10 fixlist5.00
 Last Modified:  7-NOV-1989    ArticleIdent: Q29594

 The small program below demonstrates an optimization problem with
 integer calculation. The program contains about 15 COMMON variables.
 In subroutine TESTR, the following line is evaluated incorrectly:

    IST=KS+2*IS-2

 The line should evaluate to 143=141+2*2-2; however, it evaluates to
 163.

 To work around the problem, do the following:

 1. Disable the optimization with compiler option /Od.

 2. Delete any of the four statements after the COMMON statement in
    TESTR. (Note that none of these four lines changes any variables
    used in the calculation of IST.)

 3. Make the COMMON variables local variables.

 Microsoft has confirmed this to be a problem in Versions 4.00, 4.01,
 and 4.10 of the FORTRAN compiler. This problem was corrected in
 Version 5.00.

 The following program demonstrates the problem:

 C   PROGRAM TO TEST INTEGER CALCULATION FAILURE
       IMPLICIT REAL*8(A-H,O-Z)
       COMMON/TSTCOM/IPT,NU,NV,NPTS,MX,NX,KF,KS,KT,KNT,NPCH,LF,LS,LT,IND
       AVE = 0.0D0
       IX = 1
       KF = 1
       IS = 2
       KS = 141
       NU = 11
       NV = 7
       NX = 12
       CALL TESTR (IX,IS)
       END

       SUBROUTINE TESTR (IX,IS)
       IMPLICIT REAL*8(A-H,O-Z)
       COMMON/TSTCOM/IPT,NU,NV,NPTS,MX,NX,KF,KS,KT,KNT,NPCH,LF,LS,LT,IND
 C
 C************* IF ANY OF THE FOLLOWING 4 LINES IS OMITTED, COMMON IS
 C************* REMOVED AND VARIABLES MOVED TO LOCAL VARIABLES IN THIS
 C************* PROGRAM OR IF THE ROUTINES ARE COMPILED USING MICROSOFT
 C************* FORTRAN 3.20, THE VARIABLE "IST" IS CORRECTLY COMPUTED
 C************* AS 143.  IF THIS ROUTINE AND THE MAIN PROGRAM ARE USED
 C************* AS SHOWN HERE "IST" IS SET TO 163.
       IFT=IS
       IST=KF+2*IS-2
       IF(IX.EQ.2) GOTO 20
       IFT=(IS-1)*NU+1
 C*************
       WRITE(*,18)KS,IS
    18 FORMAT(' KS =',I4,', IS =',I3)
       IST=KS+2*IS-2
       WRITE(*,19)IST
    19 FORMAT(' IST =',I4)
    20 RETURN
       END


 266. Run-Time Error 2101

 Product Version(s): 3.20
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 12-MAY-1988    ArticleIdent: Q10635

 Problem:
    The following program generates run-time error 2101:

    complex c1
    do 100 i=1,100
    c1 = cmplx (10.0**i,10.0**i)
    write (*,*) i,csqrt(c1),cabs(c1) 100 continue
    end

 Response:
    Microsoft confirmed this to be a problem in Version 3.20 of the
 FORTRAN compiler. This problem was corrected in Version 3.30.


 267. ERRORLEVEL Flag Not Set to Attempted Compilation

 Product Version(s): 3.20
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 12-MAY-1988    ArticleIdent: Q10639

 Problem:
    The compiler does not set the ERRORLEVEL flag according to the
 results of the attempted compilation.

 Response:
    This problem was corrected in Version 3.30.


 268. Formal Parameters Greater than 64K

 Product Version(s): 3.20
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 12-MAY-1988    ArticleIdent: Q10640

 Problem:
    Formal parameters greater than 64K give specification errors if
 preceded by other formal parameters of particular byte sizes.
    It appears that 0-byte and 8-byte offsets are correct, but 4-byte
 and 12-byte offsets give an error.

 Response:
   Microsoft confirmed this to be a problem in Version 3.20 of the
 FORTRAN compiler.
   This problem was corrected in Version 3.30.


 269. Invoking PAS2 from a Batch File

 Product Version(s): 3.20
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 12-MAY-1988    ArticleIdent: Q10653

 Problem:
    A problem may occur when invoking PAS2 from a batch file. If there
 are any trailing blanks following the command "PAS2", PAS2 requests a
 RETURN before continuing.

 Response:
    Micorsoft confirmed this to be a problem in Version 3.2 of the
 FORTRAN compiler.
    This problem was corrected in Version 3.30.


 270. OPEN Statement Required or System Will Stop

 Product Version(s): 3.20
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified:  5-MAY-1988    ArticleIdent: Q10669

 Problem:
    Under the following conditions, an OPEN statement is required or
 the system will stop:

    1. Using Northstar Advantage.
    2. Running DOS Version 1.10.
    3. Using unit 0 rather than the * for console.

 Response:
    Microsoft is unable to duplicate this problem under DOS Versions
 1.00 or 2.00.


 271. Compile Error 835

 Product Version(s): 3.20
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist3.20 fixlist3.30
 Last Modified: 13-JAN-1989    ArticleIdent: Q10663

 Problem:

 The example of SAVE on Page 119 of the "Microsoft FORTRAN Reference"
 manual produces compiler error 835 in pass 1 of the compiler (FOR1).
 The following program demonstrates this problem:

    integer*4 myvar
    common /mycom/ n
    save /mycom/, myvar
    end

 Response:

 Microsoft has confirmed this to be a problem in Version 3.20 of the
 FORTRAN compiler. This problem was corrected in Version 3.30.


 272. $DEBUG Metacommand

 Product Version(s): 3.20
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 12-MAY-1988    ArticleIdent: Q10644

 Problem:
    The following program gives the run-time error "long integer math
 overflow" when compiled with $DEBUG, but runs properly without the
 metacommand:

    $DEBUG
       PROGRAM TEST
       INTEGER*4 IX

       X=327.64
       IX=32780

       DO 10 J=1,10
       IX=(X*100)
       WRITE(*,*)IX,X
      10 X=X+.01

       END

 Response:
    This problem was corrected in Version 3.30.


 273. Implied DO Loops on READ Statements

 Product Version(s): 3.20
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 12-MAY-1988    ArticleIdent: Q10643

 Problem:
    READ statements with implied DO loops are always executed at least
 once. This is not the case with explicit DO loops or WRITE statements
 with implied loops.

 Response:
    This is correct behavior for READ statements.
    The ANSI Standard says the statement 'READ(*,*) (I,J=1,0)' should
 behave the same as a READ(*,*).
    An implied DO loop in a READ is not equivalent to a real DO loop
 containing a READ.


 274. SP Edit Descriptor

 Product Version(s): 3.20
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist3.20 fixlist3.30
 Last Modified: 20-OCT-1988    ArticleIdent: Q10668

 Problem:

 The SP edit descriptor does not function correctly. It fails to put in
 plus (+) signs for positive numbers and negative numbers are
 incorrectly changed to positive. The following is a code sample that
 demonstrates this behavior:

        do 10 i1=-10,10,2
        write(*,100) i1,i1,i1
  10    continue
  100   format(' ',i3,' ',sp,i3,' ',i3)
        end

 Response:

 Microsoft confirmed this to be a problem in Version 3.20 of the
 FORTRAN compiler. This problem was corrected in Version 3.30.


 275. READ to Unit 1

 Product Version(s): 3.20
 Operating System:   MS-DOS
 Flags: enduser |
 Last Modified:  2-MAY-1988    ArticleIdent: Q10661

 Problem:
    A program opens the console as logical unit 1 in the main program.
 A subsequent "READ(1," in a subroutine fails to read any data from the
 keyboard. When the "READ (1," is replaced by a "READ (0," the program
 works properly.

 Response:
    The READ statement to unit 1 is correctly taking the error path
 because you cannot read from a unit to which you have just written
 without first doing a Rewind and BACKSPACE. You cannot rewind the
 console.
    One method to achieve your goal is to READ and WRITE from different
 units both connected to CON.


 276. Run-Time Error "Real Indefinite"

 Product Version(s): 3.20
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist3.20 fixlist3.30
 Last Modified:  7-OCT-1988    ArticleIdent: Q10637

 Problem:

 DREAL(IMAG*16) compiles without error but gives the run-time error
 "Real Indefinite". The following is a short code example that
 demonstrates this problem:

 PROGRAM TEST COMPLEX*16 A REAL*8 X,Y

 A=DCMPLX(-.121E+04,.406E+04) WRITE(*,'(3H A=,2E10.3)')A
 X=DIMAG(A) WRITE(*,'(10H DIMAG(A)=,E10.3)')X Y=DREAL(A)
 WRITE(*,'(10H DREAL(A)=,E10.3)')Y

 END

 Response:

 Microsoft confirmed this to be a problem in Version 3.20 of the
 FORTRAN compiler. This problem was corrected in Version 3.30.


 277. Run-Time Error 1232

 Product Version(s): 3.20
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist3.20
 Last Modified: 20-OCT-1988    ArticleIdent: Q10627

 Problem:

 A BLOCK DATA subprogram following the main program in a source file
 generates a run-time error 1232. The following program demonstrates
 the problem:

        program tstblk
        common /tst/i
        write (*,1)i 1 format (' ',i10)
        stop
        end
        block data
        common /tst/i
        data i/5/
        end

 Response:

 Microsoft confirmed this to be a problem in Version 3.20 of the
 FORTRAN compiler. This problem was corrected in Version 3.30.

 The workaround to this problem is to place the BLOCK DATA first in the
 source file or compile separately.


 278. AIMAG of a Complex Function

 Product Version(s): 3.20
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist3.20 fixlist3.30
 Last Modified: 20-OCT-1988    ArticleIdent: Q10625

 Problem:

 If the intrinsic function AIMAG is passed to a complex function as an
 argument, incorrect results are returned. The following program
 demonstrates the problem:

        program oct03b
        complex func2,zz
        zz = (1111.,2222.)
        write (*,*) aimag (func2 (zz))
        end
        complex function func2 (yy)
        complex yy
        func2 = (1111.,2222.)
        end

 Response:

 Microsoft confirmed this to be a problem in Version 3.20 of the
 FORTRAN compiler. This problem was corrected in Version 3.30.


 279. Array Greater Than 64K

 Product Version(s): 3.20
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 20-OCT-1988    ArticleIdent: Q10671

 Problem:

 Arrays are not always accessed correctly if they are greater than 64K
 and the subscript to the array is an expression that references the
 array itself. The following is a code sample that demonstrates this
 behavior:

        PROGRAM TEST
        DIMENSION IA(20000)
        DIMENSION IB(10)

        WRITE(*,'(12H LENGTH >64K)')
        DO 15 I=1,10
        IA(I)=I 15 WRITE(*,*)I,IA(I),IA(IA(I))

        WRITE(*,'(12H LENGTH <64K)')
        DO 18 I=1,10
        IB(I)=I 18 WRITE(*,*)I,IB(I),IB(IB(I))
        END

 Response:

 Microsoft confirmed this to be a problem in Version 3.20 of the
 FORTRAN compiler. The problem was corrected in Version 3.30.


 280. Setting the Direction Flag with MASM

 Product Version(s): 3.20
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 12-MAY-1988    ArticleIdent: Q10664

 Question:
    Setting the direction flag with an assembly language routine may
 cause the subsequent I/O operation to fail. The following source files
 demonstrate the problem:

    program dftst
    x = 1.2
    write(*, 100) 100 format(' Before direction flag has been set')
    write(*,*) x
    call dirflg
    write(*, 200) 200 format(' After direction flag has been set')
    write(*,*) x
    end

 data segment public 'data' data ends ; dgroup group data ; code segment 'code
    ASSUME CS:code, ds:dgroup, ss:dgroup
    public dirflg dirflg proc far
    std
    ret dirflg endp code ends
    end

 Response:
    The workaround for this problem is to link with DOS2FOR.


 281. Pas2 Hangs If Call Precedes Function Declaration

 Product Version(s): 3.20
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 12-MAY-1988    ArticleIdent: Q10657

 Problem:
    If a function call precedes a function declaration, the compiler
 PAS2 hangs. If the function declaration precedes the call, the code is
 correctly flagged with the error message "subroutine name expected."
    The following small-code sample demonstrates this problem:

    PROGRAM A
    CALL I
    END

    FUNCTION I
    I=0
    RETURN
    END

 Response:
    Microsoft has confirmed this to be a problem in the FORTRAN
 Compiler Version 3.20.
    The problem was corrected in Version 3.30.


 282. Compile Error 84 "FUNCTION Type Conflict"

 Product Version(s): 3.20
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 12-MAY-1988    ArticleIdent: Q10651

 Problem:
    The compiler generates an error 84 "FUNCTION type conflict" if an
 implicitly typed INTEGER function contains an IMPLICIT INTEGER*2
 declaration. The following program demonstrates the problem:

    function nvalue (nvar,mxcol,str)
    implicit integer*2 (a-z)
    real*4 fr
    dimension nvar(8,8),nfval(8,8),str(8,8),kpl(2)
    common fr
    mycol = 3 - mxcol
    do 1 i=1,8
    do 1 j=1,8 1 nfval(i,j)=0
    do 50 i=1,8
    do 50 j=1,8
    if (nvar(i,j).ne.0) nfval(i,j)=
    + ntot(i,j,nvar(i,j),nvar,str) 50 continue
    kpl(1)=0
    kpl(2)=0
    do 80 i=1,8
    do 80 j=1,8
    if (nvar(i,j).ne.0) kpl(nvar(i,j)) = kpl(nvar(i,j)) +nfval(i,j) 80 continu
    nvalue= kpl(mxcol) - kpl(mycol)
    if (kpl(mycol).eq.0) nvalue=nvalue + 500
    return
    end

 Response:
    Microsoft confirmed this to be a problem in Version 3.20 of the
 FORTRAN compiler.
    The problem was corrected in Version 3.30.


 283. Internal Error 828

 Product Version(s): 3.20
 Operating System:   MS-DOS
 Flags: enduser |
 Last Modified: 12-MAY-1988    ArticleIdent: Q10648

 Problem:
    Pass one of the compiler (FOR1) generates an internal error 828.
 This occurs if the formal parameter of a subroutine is used as an
 index variable in a READ statement with an implicit DO. The following
 program demonstrates this problem:

    SUBROUTINE EXAMPLE(I)
    DIMENSION A(80)

 C EXPLICIT DO LOOP WORKS FINE
    DO 10 I=1,10
    10 CONTINUE

 C IMPLICIT DO LOOP WORKS FINE IF VAR IS NOT FORMAL PARAMETER
    READ(*,*)(A(J),J=1,79)

 C IMPLICIT DO LOOP FAILS IF VAR IS FORMAL PARAMETER OF SUBROUTINE
    READ(*,*)(A(I),I=1,79)

    RETURN
    END

 Response:
    Microsoft has confirmed this to be a problem in Version 3.20 of the
 FORTRAN compiler. The problem was corrected in Version 3.30.


 284. Initialization of a Huge Array

 Product Version(s): 3.20
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist3.20 fixlist3.30
 Last Modified: 24-OCT-1988    ArticleIdent: Q10645

 Problem:
    When using the Microsoft FORTRAN Compiler Version 3.20,
 initialization of a huge character array fails at the 64K boundary.
    In the following example, program arry(65336) is not initialized to
 "A":

    program arrytst
    character arry(100000)
    integer*4 n, nerr
    data arry / 100000 * 'A'/
    nerr = 0
    do 200 n = 1, 100000
    if (arry(n) .ne. 'A') then
    nerr = nerr + 1
    write(*,100) n, arry(n) 100 format(' ERROR! arry(',i7,') = ',a1)
    endif 200 continue
    if (nerr .eq. 0) then
    write(*,300) 300 format(' No errors occurred!')
    endif
    end

 Response:
    Microsoft confirmed this to be a problem in Version 3.20 of the
 FORTRAN compiler.
    This problem was corrected in FORTRAN Compiler Version 3.30.


 285. Symbol Defined More Than Once

 Product Version(s): 3.20
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 12-MAY-1988    ArticleIdent: Q10620

 Problem:
    The following program specifies an external procedure IFRED. When
 linked with another module that defines IFRED, the linker generates
 the error "symbol defined more that once."
    The following program will produce this error:

    program darilek
    integer n(3)
    real pp,qq,r(100),pdif(6),rel,rels,er,ermax
    real vrince,xnr
    real ax,ans,zero,one,two,five
    double precision dseed,dzero,seed(2),sum,temp,amean
    external ifred
    i = 1
    call sub(ifred,i)
    write(*,*) i
    stop
    end

 Response:
    Microsoft confirmed this to be a problem in Version 3.20 of the
 FORTRAN compiler.
    This problem was corrected in FORTRAN Compiler Version 3.30.


 286. $Large Metacommand and Subroutines

 Product Version(s): 3.20
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 12-MAY-1988    ArticleIdent: Q10622

 Problem:
    In the following example, the array "siwork" is not being
 recognized as a large array:

 $large
    subroutine fred(siwork)
    integer*2 siwork(1)
    write (*,*) siwork(33333)
    end

 Response:
    Microsoft confirmed this to be a problem in Version 3.20 of the
 FORTRAN compiler.
    The problem was corrected in Version 3.30.


 287. Read from * Causes Triple Space Rather Than Double Space

 Product Version(s): 3.20
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist3.20 fixlist3.30
 Last Modified:  6-MAY-1988    ArticleIdent: Q10624

 Problem:
    A read from "*" causes a subsequent write to "*" to triple-space
 rather than double-space.
    The following is a short code sample that demonstrates the problem:

    character*1 ina(73)
    write(*,'(a)') ' Reference line.'
    read(*,'(73a1)')ina
    write(*,'(a)') '0< Using "0" here, double space gives triple'
    write(*,'(a)') '0double spaced.'
    write(*,'(a)') '0double spaced'
    end

 Response:
    Microsoft has confirmed this to be a problem in the FORTRAN
 Compiler Version 3.20.
    The problem was corrected in Version 3.30.


 288. DREAL Functions Used in Double Complex

 Product Version(s): 3.20
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 12-MAY-1988    ArticleIdent: Q10636

 Problem:
    Pass one of the compiler (FOR1) generates "compile time error 87"
 when processing a DREAL function used as an argument for a DCMPLX.
    The following program demonstrates this behavior:

       complex*16 x, y
       x = (0.0d0, 0.0d0)
       y = dcmplx(dreal(x), 0.0d0)
       stop
       end

 Response:
    Microsoft confirmed this to be a problem in Version 3.20 of the
 FORTRAN compiler.
    This problem was corrected in Version 3.30.


 289. INT Function Producing Incorrect Answer

 Product Version(s): 3.20
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 20-OCT-1988    ArticleIdent: Q10647

 Problem:

 The function INT produces an incorrect answer if given a mixed-mode
 expression. The following code sample returns the value 94 (it should
 return the value 95):

        s = .95
        n = 100
        i = int (n*s)
        write (*,*) s,n,i
        x = n*s
        j = int(x)
        write (*,*) x,j
        end

 Response:

 This is not a problem with the compiler. The different values in the
 above example are obtained because, in the first case, truncation
 occurs after the value has been rounded to an 80-bit representation of
 the expression 100 * .95. In the second case, truncation occurs after
 the value has been rounded to a 32-bit representation.


 290. LEN Function

 Product Version(s): 3.20
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified:  6-OCT-1988    ArticleIdent: Q10667

 Problem:

 The FORTRAN intrinsic LEN is missing from this version of the
 compiler; however, it will compile and link without error if you use
 the LEN function in a program. The result from the LEN function is
 always 538976288. The following is a code sample that demonstrates
 this behavior:

        character*20
        alphaline = 'This is a test'
        i = len(alphaline)
        write (*,10) i
 10     format (1x,i16)
        end

 Response:

 The LEN intrinsic function is not supported in this version of the
 compiler. However, the LEN intrinsic function was implemented in a
 peculiar manner in that the front end recognizes the LEN as an
 intrinsic, but generates incorrect code. In Version 3.30, LEN is not
 recognized at all. In Version 4.00, LEN is fully supported.


 291. FORTRAN Version 4.10 README DOC: Pascal Programs

 Product Version(s): 4.10   | 4.10
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified: 13-JAN-1989    ArticleIdent: Q28824

 The following information is from the FORTRAN Version 4.10
 CVREADME.DOC file:

 Microsoft Pascal Programs

 In this release, Microsoft Pascal programs cannot be debugged with the
 CodeView debugger. However the Pascal 4.00, just released, does have
 CodeView support.

 The Pascal example on Page 61 of the Microsoft CodeView and Utilities
 manual should read

 PAS1 /Z TEST;

 rather than

 PAS1 /Zi TEST;

 Although, the PL driver does use the "/Zi" switch.


 292. FORTRAN 4.10 CVREADME.DOC: Overlay Restrictions

 Product Version(s): 4.10   | 4.10
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified: 27-APR-1988    ArticleIdent: Q28825

    The following information is from the FORTRAN Version 4.10
 CVREADME.DOC file:

 Overlay Restrictions
    You cannot use long jumps (using the longjmp library function) or
 indirect calls (through a function pointer) to pass control to an
 overlay. When a function is called through a pointer, the called
 function must be in the same overlay or in the root.


 293. FORTRAN 4.10 CVREADME.DOC: Library Manager

 Product Version(s): 4.10   | 4.10
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified: 27-APR-1988    ArticleIdent: Q28826

    The following information is from the FORTRAN Version 4.10
 CVREADME.DOC file:

 Microsoft Library Manager (LIB) -- New Option
    There is a new option for LIB: /NOIGNORECASE (abbreviated as /N).
 This option tells LIB to not ignore case when comparing symbols.
 names. By default, LIB ignores case. Multiple symbols that are the
 same except for case can be put in the same library. An example of
 this is: "_Open" and "_open". Normally you could not add both these
 symbols to the same library.
    Note that if a library is built with /NOI, the library is
 internally "marked" to indicate /NOI. All libraries built with
 earlier versions of LIB are not marked.
    If you combine multiple libraries, and any one of them is marked
 /NOI, then /NOI is assumed for the output library.
    In addition, LIB also supports the option /IGNORECASE (/I), which
 is completely analogous to /NOIGNORECASE. /I is the default. The only
 reason to use it would be if you have an existing library marked /NOI
 that you wanted to combine with other libraries which were not marked,
 and have the output library be not marked. If you don't use
 /IGNORECASE, the output is marked /NOI (see above).

 Changed LIB Error Messages
    Warning messages U4152, U4155, and U4157-U4159 for LIB are now
 nonfatal error messages U2152, U2155, and U2157-U2159, respectively.
    Warning message U4151 has been changed to read as follows:

    U4151   '<name>' : symbol defined in module <name>,
                            redefinition ignored

 New LIB Error Messages
    The following new warning messages have been added for LIB:

    U4155   <modulename> : module not in library

    A module specified to be replaced does not already exist in the
 library. LIB adds the module anyway.

    U4157   insufficient memory, extended dictionary not created
    U4158   internal error, extended dictionary not created

    For the reason indicated, LIB could not create an extended
 dictionary. The library is still valid, but the linker is not able to
 take advantage of the extended dictionary to speed linking.


 294. FORTRAN 4.10 CVREADME.DOC: ILink Warning Messages

 Product Version(s): 4.10    | 4.10
 Operating System:   MS-DOS  | OS/2
 Flags: ENDUSER |
 Last Modified:  5-MAY-1988    ArticleIdent: Q28827

    The following information is from the FORTRAN Version 4.10
 CVREADME.DOC file:

 ILINK Warning messages

    Fixup frame relative to an (as yet) undefined symbol - assuming ok
 See documentation for LINK error messages L4001 and L4002, in the
 Microsoft CodeView and Utilities manual.

    <name> contains TYPEDEFs - ignored
    <name> contains BLKDEFs - ignored
    The .OBJ file contains records no longer supported by Microsoft
 language compilers.
    Old .EXE free information lost The free list in the .EXE file has
 been corrupted. The free list keeps track of "holes" of free space in
 the EXE file. These holes are made available when segments are moved
 to new locations.
    File <name> has no useful contribution The given module makes no
 contribution to any segment.
    Main entry point moved The program starting address changed. You
 may want to consider doing a full link.


 295. FORTRAN 4.10 Patch README.DOC: IBM PC-DOS 3.20

 Product Version(s): 4.10    | 4.10
 Operating System:   MS-DOS  | OS/2
 Flags: PSSONLY | ENDUSER
 Last Modified: 30-OCT-1990    ArticleIdent: Q28828

    The following information is from the FORTRAN Version 4.10 Patch
 README.DOC file:

    There is a bug in IBM PC-DOS 3.20 which may cause improper
 operation of a program if a floating point exception is generated.
 This patch to IBM PC-DOS 3.20 is provided to insure proper operation
 of programs which may generate floating point exceptions. In
 particular, the C runtime routine signal with the SIGFPE parameter
 does not work with the unpatched version of IBM PC-DOS 3.20. IBM has
 also made a patch for this problem available.
    Procedure for patching IBM PC-DOS 3.20:

    1. Use the DOS sys command to transfer IBMDOS.COM and IBMBIO.COM to
 a writable diskette.
    2. Copy command.com, sys.com and debug.com from your IBM DOS 3.20
 diskette to the new diskette.
    3. Copy stkpat.bat, stkpat.scr, rmrhs.exe and setrhs.exe from the
 \patch directory to the new diskette.
    4. Reboot the system from the new diskette.
    5. Run stkpat.bat. This patches the IBMBIO.COM on the new diskette.
    6. Use the DOS sys command to transfer the patch to any other IBM
 PC-DOS 3.20 diskette.

    If you are running any version of DOS 3.20 other than IBM PC-DOS
 3.20, contact your hardware manufacturer (OEM) to find out if the
 problem exists in your DOS 3.20 version.


 296. FORTRAN 4.10 CVREADME.DOC: Stack Trace Command

 Product Version(s): 4.10   | 4.10
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified: 27-APR-1988    ArticleIdent: Q28829

    The following information is from the FORTRAN Version 4.10
 CVREADME.DOC file:

 Stack Trace Command
    In order for the Stack Trace command (or the Calls menu) to work
 reliably, you need to execute to at least the beginning of the main
 function or procedure, and the current module should have full
 CodeView information (a module has full CodeView information if
 compiled or assembled with /Zi).


 297. FORTRAN 4.10 CVREADME.DOC: Exit Codes

 Product Version(s): 4.10   | 4.10
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified: 27-APR-1988    ArticleIdent: Q28830

    The following information is from the FORTRAN Version 4.10
 CVREADME.DOC file:

 Exit Codes for Utilities
    The exit codes for LINK and the utilities in the Microsoft CodeView
 and Utilities manual should appear as follows:

 LINK

    Code    Meaning

    0       No error.

    2       Program error--something was wrong with the commands
            or files input to the linker.

    4       System error.  The linker

            - ran out of space on output files
            - was unable to reopen the temporary file
            - experienced an internal error
            - was interrupted by the user

 LIB, EXEPACK, EXEMOD, MAKE, and SETENV

    Code    Meaning

    0       No error.

    2       Program error--something was wrong with the commands
            or files input to the utility.

    4       System error.  The utility ran out of memory, was
            interrupted by the user, or experienced an internal
            error.

            Microsoft Segmented-Executable Linker (LINK)


 298. "END=" on Multiple Executions

 Product Version(s): 3.20
 Operating System:   MS-DOS
 Flags: ENDUSER | TAR50049 buglist3.20 fixlist3.30
 Last Modified:  6-OCT-1988    ArticleIdent: Q10666

 Problem:

 Using "END=" to branch works properly the first time, but can fail
 under multiple executions. The following code sample demonstrates this
 behavior:

         program contlz

         real*4 a,b

         i = 0
 10      write(*,*) 'real ?'
         read(*,*,end=200) a

         write(*,*) 'second real ?'
         read(*,*,end=200) b
         goto 100

 200     write (*,*) 'end of file encountered'
 100     write(*,*) 'end of program message'
         i = i + 1
         if (i.lt.3) goto 10
         end

 Response:

 Microsoft confirmed this to be a problem in Version 3.20 of the
 FORTRAN compiler. The problem was corrected in Version 3.30.


 299. FORTRAN 4.10 CVREADME.DOC: Changed LINK Error Messages

 Product Version(s): 4.10    | 4.10
 Operating System:   MS-DOS  | OS/2
 Flags: ENDUSER |
 Last Modified: 27-APR-1988    ArticleIdent: Q28831

    The following information is from the FORTRAN Version 4.10
 CVREADME.DOC file:

 Changed LINK Error Messages
    The explanation for fatal-error message L1008 is changed as
 follows:

    The /SEGMENTS option specified a limit greater than 3072 on the
 number of segments allowed.

    Error message L1009 has been changed to read as follows:

         L1009   <number> : CPARMAXALLOC : illegal value

    Error message L1053 has been changed to read as follows:

         L1053   out of memory for symbol table

    The program had more symbolic information (such as public,
 external, segment, group, class, and file names) than the amount that
 could fit in  available real memory.
    Try freeing memory by linking from the DOS command level instead of
 from a MAKE file or from an editor. Otherwise, combine modules or
 segments and try to eliminate as many public symbols as possible.
    Warning message L4050 has been changed as follows:

         L4050   too many public symbols for sorting

    The linker uses the stack and all available memory in the near heap
 to sort public symbols for the /MAP option. If the number of public
 symbols exceeds the space available for them, this warning is issued,
 and the symbols are not sorted in the map file but are listed in
 arbitrary order.


 300. FORTRAN 4.10 CVREADME.DOC: New LINK Error Messages

 Product Version(s):
 Operating System:   4.10   | 4.10
 Flags: MS-DOS | OS/2
 Last Modified: 29-AUG-1988    ArticleIdent: Q28832
 ENDUSER |

    The following information is from the FORTRAN Version 4.10
 CVREADME.DOC file:

 New LINK Error Messages

    L1003   /QUICKLIB, /EXEPACK incompatible

    You cannot link with both the /QU option and the /E option.

    L1006   <option-text>: stack size exceeds 65535 bytes

    The value given as a parameter to the /STACKSIZE option exceeds the
 maximum allowed.

    L1063   out of memory for CodeView information

    The linker was given too many object files with debug information,
 and the linker ran out of space to store it. Reduce the number of
 object files that have debug information.

    L1115   /QUICKLIB, overlays incompatible

    You specified overlays and used the /QUICKLIB option. These cannot
 be used together.

    L2013   LIDATA record too large

    An LIDATA record contained more than 512 bytes. This is probably a
 compiler error.

    L2024   <name>: special symbol already defined

    Your program defined a symbol name that is already used by the
 linker for one of its own low-level symbols. (For example, the linker
 generates special symbols used in overlay support and other
 operations.) Choose another name for the symbol in order to avoid
 conflict.

    L2025   <segmentname>: segment with > 1 class name not allowed with
 /INC

 ******<The following is a correction to the CVREADME.DOC file.>*******
    The above error number is not correct. L2025 refers to Symbol
 defined more than once.
 *****************************<END>************************************

    Your program defined a segment more than once, giving the segment
 different class names. Different class names for the same segment are
 not allowed when you link with the /INCREMENTAL option. Normally, this
 error should never appear unless you are programming with MASM. For
 example, if you give the two MASM statements

    _BSS segment 'BSS'

    and

    _BSS segment 'DATA'

 then the statements have the effect of declaring two distinct
 segments. ILINK does not support this situation, so it is disallowed
 when the /INCREMENTAL option is used.

    L2041   stack plus data exceed 64K

    The total of near data and requested stack size exceeds 64K, and
 the program will not run correctly. Reduce the stack size. The linker
 only checks for this condition if /DOSSEG is enabled, which is done
 automatically in the library startup module.

    L2043   Quick Library support module missing

    When creating a Quick library, you did not link with the required
 QUICKLIB.OBJ module.

    L2044   <name> : symbol multiply defined, use /NOE

    The linker found what it interprets as a public-symbol
 redefinition, probably because you have redefined a symbol that is
 defined in a library. Relink with the /NOEXTDICTIONARY (/NOE) option.
 If error L2025 results for the same symbol, then you have a genuine
 symbol-redefinition error.

    L4003   intersegment self-relative fixup at <offset> in segment
 <name> pos: <offset> Record type: 9C target external '<name>'

    The linker found an intersegment self-relative fixup. This error
 may be caused by compiling a small-model program with the /NT option.

    L4034   more than 239 overlay segments; extra put in root

    Your program designated more than the limit of 239 segments to go
 in overlays. Starting with the 234th segment, they are assigned to
 the root (that is, the permanently resident portion of the program).


 301. BACKSPACE Working Improperly

 Product Version(s): 3.20
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 20-OCT-1988    ArticleIdent: Q10711

 Problem:

 BACKSPACE does not seem to work properly using the DOS1 unit v. The
 following is a code sample that demonstrates this behavior:

        program xxx
        character*70 line
        open (1,file=' ',status='old') 100 continue
        read (1,110,end=200) line 110 format (a)
        write (*,*) line
        go to 100 200 continue
        if (eof(1)) write (*,*) 'unit 1 is at eof'
        backspace 1
        write (1,900) '*****this is new info****' 900 format
     (a)
        write (1,900) 'and so is this...!'
        end

 Response:

 A workaround to this problem is to link with DOS2FOR.LIB. Because
 future versions of the compiler will no longer support DOS1 unit v,
 the problem will no longer occur.


 302. FORTRAN 4.10 CVREADME.DOC: Mixed-Language Programming

 Product Version(s): 4.10   | 4.10
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified: 27-APR-1988    ArticleIdent: Q28833

    The following information is from the FORTRAN Version 4.10
 CVREADME.DOC file:

 Mixed-Language Programming -- C Naming Conventions
    C recognizes the first 31 characters of a symbolic name.

 Accessing Parameters on the Stack
    In Section 6.1.5 of the Microsoft Mixed Languages Programming
 Guide, the instruction

         mov     bx, [bp+6]

 loads the argument into the BX register rather than the BP register.

 Setting Up Calls to High-Level Languages
    Section 6.6 of the Microsoft Mixed Languages Programming Guide
 gives instructions for setting up a call to a high-level language from
 assembly language. Before you execute a call to a BASIC, Pascal, or
 FORTRAN routine, remember to declare an additional parameter if the
 return value is noninteger. This additional parameter must contain the
 offset address of the return value, for which you must allocate room
 within the stack segment (normally DGROUP, the same as the default
 data segment).

 BASIC Return Values
    BASIC functions use the FORTRAN/Pascal conventions, rather than the
 C conventions, for receiving return values.

 Passing C Strings to BASIC
    In Section 8.4.3 of the Microsoft Mixed Languages Programming
 Guide, in the example illustrating how C passes string arguments to
 BASIC functions, the sd_len field should be declared as shown below:

         int sd_len

 BASIC Array Declarations
    The sample BASIC array declaration in Table 9.1 of the Microsoft
 Mixed Language Guide should read

         DIM x(c-1, r-1)

 Linking with MASM Files
    If you are linking C modules with modules created by the Microsoft
 Macro Assembler, either assemble the MASM modules with the /MX option
 to preserve case sensitivity in these modules; or, use the LINK
 command to link in a separate step, and do NOT specify the /NOI linker
 option.

 Linking Mixed-Language Programs
    This section explains how to link Microsoft C modules with modules
 created by other Microsoft languages. The discussions assume that you
 are linking with the Microsoft Segmented-Executable Linker, LINK.
 (This is the version of LINK provided with this version of FORTRAN and
 Version 5.10 of the Microsoft C Optimizing Compiler.)
    To link object modules created using the Microsoft C Optimizing
 Compiler, Version 5.10, with those created using the Microsoft FORTRAN
 Optimizing Compiler Version 4.00 or 4.01, you must create a special
 version of each of the FORTRAN libraries you intend to use. Create one
 FORTRAN library to correspond to each C library you are using; that
 is, create a FORTRAN library that supports the same
 memory-model/math-option combination as the corresponding C library.
 Be sure that you choose the "C compatibility" option when you build
 each FORTRAN library.
    Next, use the SETUP program provided with Microsoft C, Version
 5.10, to create all the combined C 5.10 libraries that you will need.
 SETUP creates a subdirectory named \MIXLANG under the C 5.10 base
 directory.
    Place the FORTRAN libraries you have created in this directory.
 Then make the \MIXLANG directory the current directory and run
 F4COMPAT, which brings the FORTRAN libraries up to date and makes them
 compatible with C 5.10. F4COMPAT takes two arguments: one specifying
 the memory model and one specifying the floating-point-math package
 that the library supports. For example,

         F4COMPAT L 7

 makes a C 5.10-compatible version of LLIBFOR7.LIB.

    Once the libraries are built, use the following LINK command line
 to link the appropriate C library with the FORTRAN library that you
 converted in the previous example:

      LINK objs,,,LLIBC7.LIB LLIBFOR7.LIB /NOE;

    The LINK command lines for other memory models and floating-point
 math packages are similar. Note that the C library must be given
 first on the command line. Specify the \MIXLANG subdirectory either in
 the LIB environment variable or on the LINK command line so that the
 linker can find the FORTRAN library. Use only large- and medium-model
 libraries. Huge-model programs use large-model libraries.
    To link other combinations of language libraries, the BASIC
 libraries (either BCOM40 or BRUN40) should be listed first on the LINK
 command line, since the main program must be written in BASIC.
 Otherwise, the C 5.10 library should be listed first. (Or, if you are
 using C 4.00 with FORTRAN 4.00 or later, the FORTRAN library should be
 listed first.) For best results, using large-memory-model C is
 suggested.


 303. FORTRAN 4.10 CVREADME.DOC: The BIND Utility

 Product Version(s): 4.10    | 4.10
 Operating System:   MS-DOS  | OS/2
 Flags: ENDUSER |
 Last Modified: 27-APR-1988    ArticleIdent: Q28834

    The following information is from the FORTRAN Version 4.10
 CVREADME.DOC file:

 The BIND Utility -- Specifying Libraries
    You need to include DOSCALLS.LIB on the BIND command line. If
 DOSCALLS.LIB is not in the current directory, you must give the
 complete path name to DOSCALLS.LIB.
    BIND automatically searches for API.LIB by looking in directories
 listed in the LIB environment variable. However, if API.LIB is
 specified on the command line, then BIND does not check the LIB
 environment variable; instead, you need to give the complete path
 name.
    For example, the following command line successfully uses BIND, if
 API.LIB is located in a directory listed in the LIB environment
 variable:

 BIND FOO.EXE \LIB\DOSCALLS.LIB

 Using BIND with Packed Files
    The version of BIND released with this package does not work with
 files that have been linked with the /EXEPACK linker option.

 Running Bound Files with DOS 2.1
    A dual-mode executable file produced with BIND can be run in both
 DOS 3.x and DOS 2.x environments. However, if you change the name of
 an executable file produced by BIND, then it will not run under DOS
 2.1.


 304. FORTRAN 4.10 CVREADME.DOC: ILink Fatal Error Messages

 Product Version(s): 4.10    | 4.10
 Operating System:   MS-DOS  | OS/2
 Flags: ENDUSER |
 Last Modified: 27-APR-1988    ArticleIdent: Q28835

    The following information is from the FORTRAN Version 4.10
 CVREADME.DOC file:

 The Microsoft Incremental Linker (ILINK) -- ILINK Fatal Error Messages

 .sym seek error
 .sym read error

    The .SYM file is corrupted. Do a full link. If the error persists,
 contact Microsoft.

 .sym write error

    The disk is full or the .SYM file already exists with the READONLY
 attribute.

 map for segment <name> exceeds 64K

    The symbolic information associated with the given segment exceeds
 64K bytes, which is more than ILINK can handle.

 can't ilink library <name>

    You tried to incrementally link an altered library. ILINK does not
 link .LIB files but only .OBJ files. Use a full link instead.

 .obj close error

    The operating system returned an error when ILINK attempted to
 close one of the .OBJ files. Do a full link. If the error persists,
 contact Microsoft.

 too many LNAMES in <modname>

    An object module has more than 255 LNAME records.

 too many SEGDEFs in <modname>

    The given object module has more than 100 SEGDEF records.

 too many GRPDEFs in <modname>

    The given object module has more than 10 GRPDEF records.

 symbol <name> multiply defined

    The given symbol is defined more than once.

 #3

    Please report this error to Microsoft.

 Out of Memory

    ILINK ran out of memory for processing the input. If you are
 running ILINK under MAKE, try running it from the shell. Otherwise, do
 a full link.

 could not run exec

    ILINK was unable to find the file EXEC.EXE, which should be placed
 somewhere in the search path or in the current directory.

 .exe file too big, change alignment

    The segment sector alignment value in the .EXE file is too small to
 express the size of one of the segments.  Do a full link and increase
 the alignment value with the /ALIGNMENT option to LINK.

 .ilk seek error

    The .ILK file is corrupted. Do a full link. If the error
 persists, contact Microsoft.

 Too many defined segments

    ILINK has a limit of 255 defined segments, which are segments
 defined in an object module as opposed to an executable segment.
 Reduce the number of segments if you want to use ILINK.

 too many library files

    ILINK has a limit of 32 runtime libraries (.LIB files). Reduce the
 number of libraries.

 too many modules

    ILINK has a limit of 1204 modules in a program. Reduce the number
 of modules.

 .ilk write error

    The disk is full, or else ILINK cannot write to the .SYM file
 because a .SYM file currently exists and has the READONLY attribute.

 file <name> does not exist

    ILINK was unable to open the given file. The file named was in the
 file list in the .ILK file.

 seek error on library

    A .LIB file was corrupted. Do a full link and check your .LIB
 files.

 library close error

    The operating system returned an error when ILINK attempted to
 close one of the .LIB files. Do a full link. If the error persists,
 contact Microsoft.

 error closing EXE file

    The operating system returned an error when ILINK attempted to
 close the .EXE file. Do a full link. If the error persists, contact
 Microsoft.

 Invalid module reference <module>

    The program makes a dynamic link reference to a dynamic link module
 which is not represented in the .EXE file.

 could not update time on <filename>

    The operating system returned an error when ILINK attempted to
 update the time on the given file. Possibly the file had the READONLY
 attribute set.

 invalid flag <flag>
 only one -e command allowed

    The ILINK command syntax is incorrect.

 User Abort

    The user issued CTRL+C or CTRL+BREAK.

 file <name> write protected

    The .EXE, .ILK, or .SYM file needed to be updated and has the
 READONLY attribute. Change attribute to READWRITE.

 file <name> missing

    One of the .OBJ files specified on the command line is missing.

 file <name> invalid .OBJ format
 file <name> has invalid <recordtype> record

    The given .OBJ file has an invalid format or one that is not
 recognized by ILINK. This may have been caused by a compiler or
 assembler.

 file <module> was not full linked

    An .OBJ file was specified as input to ILINK, which was not in the
 list of files in the original full link.

 LOBYTE seg-relative fixups not supported

    This error message should occur only with MASM files. See the
 Microsoft Macro Assembler 5.0 Programmer's Guide. This type of object
 module is not supported by ILINK.

 <number> undefined symbols

    The given number of symbols were referred to in fixups but never
 publicly defined in the program.


 305. FORTRAN 4.10 CVREADME.DOC: Incremental Violations

 Product Version(s): 4.10   | 4.10
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified: 27-APR-1988    ArticleIdent: Q28836

    The following information is from the FORTRAN Version 4.10
 CVREADME.DOC file:

 Incremental Violations
    These errors cause a full link to occur if the -e option is used
 and -i is not used, or else they are fatal errors:

 symbol <name> deleted

    A symbol was deleted from an incrementally-linked module.

 <modname> contains new SEGMENT

    A segment was added to the program.

 <modname> contains changed segment <name>

    The segment contribution (code or data which the module contributes
 to a segment) changed for the given module: it contributed to a
 segment it didn't previously contribute to, or a contribution was
 removed.

 <modname>'s segment <name> grew too big

    The given segment grew beyond the padding for the given module.

 <modname> contains new GROUP <name>

    A new group was defined, via the GROUP directive in assembly
 language or via the /ND C compiler option.

 <modname> redefines group <name> to include <name>

    The members of the given group changed.

 symbol <name> changed

    The given data symbol was moved.

 can't add new communal data symbol <name>

    A new communal data symbol was added as an uninitialized variable
 in C or with the COMM feature in MASM.

 communal variable <name> grew too big

    The given communal variable changed size too much.

 invalid symbol type for <name>

    A symbol which was previously code became data, or vice versa.

 too many COMDEFS
 too many EXTDEFS

    The limit on the total of COMDEF records (communal data variables)
 and EXTDEF records (external references) is 2000.

 invalid CodeView information in .EXE file

    The CodeView information found is invalid.

 <name> contains new CodeView symbolic info

    A module previously compiled without -Zi was compiled with -Zi.

 <name> contains new linnum info

    A module previously compiled without -Zi or -Zd was compiled with
 -Zi or -Zd.

 <name> contains new public CV info

    New information on public-symbol addresses was added.

 invalid .exe file

    The .EXE file is invalid. Make sure you are using an up-to-date
 linker. If the error persists, contact Microsoft.

 invalid .ilk file
 .ilk read error
 .ilk seek error

    The .ILK file is invalid. Make sure you are using an up-to-date
 linker. If the error persists, contact Microsoft.

 .SYM/.ILK mismatch

    The .SYM and .ILK files are out of sync. Make sure you are using
 an up-to-date linker. If the error persists, contact Microsoft.

 <libname> has changed

    The given library has changed.

 can't link 64K-length segments

    ILINK cannot handle segments greater than 65,535 bytes long.

 can't link iterated segments

    ILINK cannot handle programs linked with /EXEPACK.

 Entry table expansion not implemented

    The program call tree changed in such a way that ILINK could not
 handle it.

 file <name> does not exist

    The .EXE, .SYM, or .ILK files are missing.

 <name> has changed

    The given library module name has changed.


 306. FORTRAN 4.10 CVREADME.DOC: Microsoft Editor

 Product Version(s): 4.10   | 4.10
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified: 27-APR-1988    ArticleIdent: Q28837

    The following information is from the FORTRAN Version 4.10
 CVREADME.DOC file:

 Microsoft Editor -- Setting Up the Microsoft Editor
    The FORTRAN setup program does not install the Microsoft Editor.
 To install the Microsoft Editor, insert the Microsoft Editor disk and
 run the MSETUP batch file. To use the MSETUP batch file under
 protected-mode OS/2, rename MSETUP.BAT to MSETUP.CMD.

 CALLTREE.EXE
    The CALLTREE program mentioned on page 112 of the Microsoft Editor
 User's Guide is not included with FORTRAN Version 4.10 because the
 utility can only be used with C and assembly programs.

 C Extension Files
    The files mentioned in Section 8, "Programming C Extensions," in
 the Microsoft Editor User's Guide are not included with FORTRAN
 Version 4.1, although this file includes corrections to the manual.

 Keystroke Configurations
    Some of the keystroke configurations listed in Table A.2 of the
 Microsoft Editor User's Guide may need to be changed.
    In the Quick/WordStar(R) configuration, the Sinsert function is
 assigned to ALT+INS, not CTRL+INS.
    In the BRIEF(R) configuration, the Plines function is assigned to
 ALT+D, and the Refresh function is assigned to CTRL+].
    In the EPSILON(TM) configuration, the Ppage function is assigned to
 PGDN, and the Sdelete function is assigned to DEL and CTRL+D.

 The Compile Function
    The commands

         Arg streamarg Compile
         Arg textarg Compile

 each use the command specified by the extmake:text switch. The editor
 does not check the extension of the file name given as an argument,
 but instead uses the "text" extension. The streamarg or textarg
 replaces a %s in the command. These commands are typically used to
 invoke MAKE.

 The Setfile Function
    The commands that use Setfile, along with a streamarg or textarg,
 accept a variety of input: either the name of a file, a file name with
 a wild-card character (* or ?), the name of a directory, or the name
 of a disk drive. File names can also include environment variables,
 such as $INIT. If the streamarg or textarg is a directory name, then
 the editor changes the current directory. If the argument is a drive
 name, then the editor changes the current drive. Environment
 variables are translated into directories to be searched for a file.
 For example, the following macro directs the editor to search the
 $INIT environment variable in order to find the tools.ini file:

     tools.ini := Arg "$TOOLS:tools.ini" Setfile

 Entering Strings in Macros
    When you enter a text argument directly, no characters have special
 meaning (except when the argument is interpreted as a regular
 expression). However, when you enter text as part of a macro, then
 strings inside of quotes are interpreted according to the C string
 format. This format uses a backslash followed by double quotes (\")
 to represent double quotes and it uses two backslashes (\\) to
 represent a single backslash. Therefore, to find the next occurrence
 of the string

     She wrote, "Here is a backslash: \ "

 you could use the following macro definition:

     findit := Arg "She wrote, \"Here is a backslash: \\ \"" Psearch

    Note that to indicate a backslash for a regular expression that is
 also part of a macro definition, you must use four consecutive
 backslashes.

 Using Text Switches
    The text switches extmake and readonly each take a special kind of
 syntax that allows you to specify drive, file name, base name, or file
 extension. The syntax consists of the characters:

 %|<letters>F

 where <letters> consists of any of the following: "p" for path, "d"
 for drive, "f" for file base name, or "e" for file extension. For
 example, if you are editing the file c:\dir1\sample.c, and you make
 the following switch assignment:

 extmake:c cl /Fod:%|pfF %|dfeF

 then each time you give the command <Arg><Compile>, the editor
 performs the following system-level command:

 cl /Fod:\dir1\sample c:sample.c

    The expression "%s" is equivalent to "%|feF" except that the former
 only works once, whereas the latter can appear any number of times in
 the extmake switch assignment. The expression "%|F" is equivalent to
 "%|dpfeF".

 The Filetab Switch
    The filetab switch is a numeric switch that determines how the
 editor translates tabs when loading a file into memory.  The value of
 the switch gives the number of spaces associated with each tab column.
 For example, the setting "filetab:4" assumes a tab column every 4
 positions on each line. Every time the editor finds a tab character
 in a file, it loads the buffer with the number of spaces necessary to
 get to the next tab column. Depending on the value of the entab
 switch, the editor also uses the filetab switch to determine how to
 convert spaces into tabs when writing to a file. The default value of
 filetab is 8.

 Functions Callable by C Extensions
    The following list summarizes functions from the standard compact-
 memory-model library, which should work when called by a C-extension
 module.  (The technique of programming C extensions is presented in
 Chapter 8 of the Microsoft Editor User's Guide.)  The memory model of
 the extension is assumed to be /Asfu (small code pointers, far data
 pointers, and stack segment unequal to data segment).  This list uses
 the function categories from Chapter 4 of the Microsoft C Optimizing
 Compiler Run-Time Library Reference (Version 4.0 or later.)

    Buffer Manipulation: All functions can be called.
    Character Classification and Conversion: All functions can be
 called.
    Data Conversion: All functions can be called except for

      strtod()

    Directory Control: All functions can be called except for

      getcwd()

    File Handling: All functions can be called.

    Low-Level I/O Routines: All functions can be called, but write()
 will not work in binary mode.
    Console and Port I/O: All functions can be called except for

      cgets()
      cprintf()
      cscanf()

    Searching and Sorting: All functions can be called except for

      qsort()

    String Manipulation: All functions can be called except for

      strdup()

    BIOS Interface: All functions can be called.
    MS-DOS Interface: All functions can be called except for

      int86()
      int86x()

    Time: All functions can be called except for

      ctime()
      gmtime()
      localtime()
      utime()

    Miscellaneous: All functions can be called except for

      assert()
      getenv()
      perror()
      putenv()
      _searchenv()

 Linking Extensions in Protected Mode
    To link C extension modules in protected mode, link with the object
 file EXTHDRP.OBJ, instead of the real-mode header EXTHDR.OBJ.


 307. FORTRAN 4.10 Startup README.DOC: Startup Sources

 Product Version(s): 4.10   | 4.10
 Operating System:   MS-DOS | OS/2
 Flags: PSSONLY | ENDUSER
 Last Modified: 30-OCT-1990    ArticleIdent: Q28838

    The following information is from the FORTRAN Version 4.10
 Startup README.DOC file:

 FORTRAN Runtime Library Startup Sources
    The directory \startup and its subdirectories contain the files
 necessary for building the startup portion of the FORTRAN run-time
 library. The \startup directory contains the startup source files, the
 include include files, the batch file and the make file used to build
 the startup object files. The subdirectories of \startup contain OS
 specific sources.
    The startup object files can be built by invoking startup.bat from
 within the \startup directory. This batch file assumes the following:

    1. make.exe, link.exec, the FORTRAN compiler, and the assembler
 must be in the execution path. MASM 5.0 or later is required to build
 the startup sources.
    2. doscalls.lib must be in the directory specified by the LIB
 environment variable.
    3. For linking the nulbody program, startup.bat assumes that
 directories containing the FORTRAN libraries (llibfor7.lib and
 mlibfor7.lib, or llibfore.lib and mlibfore.lib) are in the library
 search path (LIB environment variable). (The alternative math
 libraries could be used if the option -FPa is added to $(FL) in the
 makefile.)

    Startup will create two memory model specific subdirectories (M and
 L) and place the appropriate object files there. Under each memory
 model subdirectory, startup creates two additional subdirectories, OS2
 and DOS, where OS specific objects reside.
    The message "<cEnd - nogen>" is generated when some of the assembly
 language source files are assembled. This message is expected and is
 totally benign.
    The startup batch file requires as arguments a list of capital
 letters describing the memory models you wish to build. For example,
 "startup M L" will build the medium and large model startup objects.
 Startup will then link the objects with a sample FORTRAN program
 called nulbody.for to produce nulbody.exe. [Invoking startup.bat with
 no arguments will give usage information.]
    Note: startup sources written in assembly language have been edited
 with tabstops set to 8.
    The following files are contained in the \startup directory:

 Startup source files (OS independent):

         chkstk.asm
         chksum.asm
         crt0fp.asm
         onexit.asm

 Startup source files (OS specific):

         crt0.asm
         crt0dat.asm
         crt0msg.asm
         nmsghdr.asm
         stdalloc.asm
         stdenvp.asm
         stdargv.asm

 Startup include files:

         brkctl.inc
         cmacros.inc
         msdos.inc
         version.inc

 Make and batch files:

         startup.bat:    invokes make file to build objs and link to
                         null program
         makefile:       contains rules for building startup sources
         nulbody.for:    null FORTRAN program
         nulbody.lnk:    link script for linking null program

 Documentation:

         readme.doc:     information about \startup directory structure
                         and contents

                                 --- End ---


 308. FORTRAN 4.10 CVREADME.DOC: Program Maintenance Utility

 Product Version(s): 4.10   | 4.10
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified: 27-APR-1988    ArticleIdent: Q28840

    The following information is from the FORTRAN Version 4.10
 CVREADME.DOC file:

 Microsoft Program Maintenance Utility (MAKE) -- New Error Message

    U1015: <file> : error redirection failed

    This error occurs if the /X option is given and error output cannot
 be redirected to the given file (for example, because the file is
 read-only).

 Inference Rules
    You cannot have inference rules in both the TOOLS.INI and the
 description file that use both the same inextension and outextension.
 For example, you cannot place the following inference rule in the
 TOOLS.INI file:

         .c.obj:
                 cl /c /Zi /Od $*.c

 while also placing the following line in the description file:

         .c.obj:
                 cl /Ot $*.c

    However, you can define the same macro in both the TOOLS.INI and
 the description file. In such cases, the definition in the description
 file takes precedence.

 Backslash (\) as Continuation Character
    Note that MAKE considers a backslash immediately followed by a
 new-line character to be a continuation character. When it finds this
 combination in a description file, MAKE continues the line
 immediately following the combination with the line where the
 combination appears.
    If you define a macro that ends in a backslash, make sure that you
 put a space after the terminating backslash. For example, if you want
 to define macros for the path C:\SRC\BIN and C:\SRC\LIB, you must use
 the format illustrated below:

         BINPATH=C:\SRC\BIN\<space><newline>
         LIBPATH=C:\SRC\LIB\<space><newline>

    To illustrate the problems that can result if you do not put a
 space before the new-line character, assume that the macros above
 appear as shown below instead:

         BINPATH=C:\SRC\BIN\<newline>
         LIBPATH=C:\SRC\LIB\<newline>

    Because a new-line character appears immediately after the
 backslash at the end of the first macro, MAKE assumes that you are
 defining the single macro shown below:

         BINPATH=C:\SRC\BIN\LIBPATH=C:\SRC\LIB\

 Microsoft STDERR Redirection Utility (ERROUT)
    The ERROUT utility does not accept batch files. To redirect
 standard-error output from a batch file, you must enter a command of
 the following form:

         ERROUT COMMAND /c <batchcommand>

    If no /f option is given, then ERROUT redirects standard-error
 output to the standard-output device.


 309. "Share Not Installed" Incorrectly Produced in Protected Mode

 Product Version(s): 4.10
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 12-MAY-1988    ArticleIdent: Q29562

    The following code will generate the error message "share not
 installed" when it is run in protected mode:

        OPEN(UNIT=7,FILE=FL,STATUS='NEW',MODE='READWRITE',
      +  SHARE='DENYWR')
        WRITE(7,'(A12)')'ARE YOU OPEN'
        write (7,*)'hello'
       END

    Trying to open a file with status = 'new' when the file already
 exists will incorrectly produce the error message "share not
 installed." The correct error message is "file already exists".
    This error only occurs in protected mode.


 310. Version 3.31 Cannot Pass a Logical Expression

 Product Version(s): 3.31
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 12-MAY-1988    ArticleIdent: Q10822

 Problem:
    The following code generates incorrect results:

    real rsw
    logical ll
    real r

    ll = .TRUE.
    write (0,*) rsw(ll,1.0,0.0)
    ll = .FALSE.
    write (0,*) rsw(ll,1.0,0.0)

    r = 1.0
    write (0,*) rsw(r .gt. 0.0,1.0,0.0)

    write (0,*) rsw(r .lt. 0.0,1.0,0.0)
    end

    real function rsw (l,t,f)
    logical l
    real t,f

    rsw = f
    if (l) rsw = t
    return
    end

    The following output is produced:

    1.0000000
    .0000000
    .0000000
    .0000000

 Response:
    Version 3.31 of the compiler does not pass logical expressions in a
 parameter list correctly.
    The following are two workarounds:

    1. Define the function before calling it.
    2. Create an INTERFACE statement for the function.

    This problem was corrected in Version 4.00.


 311. Symbol Defined More Than Once

 Product Version(s): 3.30
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist3.30
 Last Modified: 12-MAY-1988    ArticleIdent: Q10809

    The false link error "symbol defined more than once" is generated
 when an object module has an external reference to a function that is
 never used.

    A workaround is to remove the external statement for the unused
 function.
    Microsoft confirmed this to be a problem in Version 3.30 of the
 FORTRAN compiler. This problem was corrected in Version 3.31.


 312. Microsoft Floating Point Versus IEEE

 Product Version(s): 3.2 3.3x 4.0x
 Operating System:   MS-DOS
 Flags: enduser |
 Last Modified:  2-MAY-1988    ArticleIdent: Q10866

 Question:
    I have created files containing floating point values in BASIC and
 would like to use these files in FORTRAN. How would I accomplish this?

 Response:
    Since Basic uses Microsoft floating point binary format to store
 real values and FORTRAN uses the IEEE format, you would have to
 convert your real values from Microsoft floating point binary to IEEE.
    To accomplish this procedure using single precision, please see
 Page 167 of the FORTRAN user's guide.
    To accomplish this procedure using double precision numbers, you
 would have to do the following:

    1. Write a BASIC program to read the numerical data files, and then
 create an output file in text (ASCII) format.
    2. Write a FORTRAN program to read the text file, and then write a
 binary file that contains the double precision numbers in the IEEE
 floating point format (FORTRAN-readable format).


 313. Run-Time Error "No Room in Heap"

 Product Version(s): 3.30
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 12-MAY-1988    ArticleIdent: Q10860

 Problem:
    I have developed a program that has about 150 subroutines (400K
 code and 120K data). Most of the data is in common blocks, but the
 error message "no room in heap" still is generated at run time.

 Response:
    The following is a list of possible reasons for this error:

    1. There may not be enough memory in your machine. The maximum
 memory you can have in your machine is 640K. You will constantly reach
 your limit unless you have a full 640K (and perhaps even if you do)
 because your data and code use 520K (400K for code, 120K for data).
    2. Something in your code may be using up DGROUP space. An error
 indicating there is no room in the heap may occur when you are opening
 a file in your program. Opening a file uses dynamic memory allocation,
 which requires space from DGROUP. If there is not enough space left in
 DGROUP, opening a file will result in a "no room in heap" error.
    3. Your format strings may be using up DGROUP space. If this is the
 case, you could put your format strings in a character variables file
 in a common block. Unfortunately, this action creates unreadable code,
 but it is a possible workaround.
    4. Long parameter lists may be using up DGROUP space, which you
 will have to break up.


 314. WRITE Statement and Parenthesis Expression

 Product Version(s): 3.30
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 12-MAY-1988    ArticleIdent: Q10817

 Problem:
    The following code

    WRITE (*,*) (1+2)*3
    END

 generates the following errors:

    Error 59, line 1 -- "=" expected
    Error 162, line 1 -- unrecognizable I/O list element
    Error 59, line 1 -- "=" expected
    Error 152, line 1 -- end of statement encountered in
    implied DO

 Response:
    These errors are generated because the compiler considers the
 expression (1+2) an implied DO list. It is illegal to put a
 parenthesis at the beginning of an output list unless it is an implied
 DO-LOOP.
    You can avoid these errors by rewriting your program as follows:

    WRITE(*,*) 3*(1+2)
    END


 315. Run-Time Error 2136

 Product Version(s): 3.30
 Operating System:   MS-DOS
 Flags: enduser | buglist3.30
 Last Modified:  2-MAY-1988    ArticleIdent: Q10812

 Problem:
    Run-time error 2136 (Real indefinite) is generated when an
 expression contains an array declared in a COMMON block and the array
 is indexed by a variable declared in the same COMMON block (but
 contained in a different segment).

 Response:
    Microsoft confirmed this to be a problem in Version 3.30 of the
 FORTRAN compiler. The problem was corrected in Version 3.31.


 316. Floating Point Expression

 Product Version(s): 3.30
 Operating System:   MS-DOS
 Flags: enduser | buglist3.30
 Last Modified:  2-MAY-1988    ArticleIdent: Q10808

 Problem:
    Floating point expressions are being evaluated incorrectly in a
 compound IF statement if a combination of REAL and INTEGER COMMON
 variables is used.

 Response:
    Microsoft confirmed this to be a problem in Version 3.30 of the
 FORTRAN compiler. The problem was corrected in Version 3.31.


 317. FORTRAN: COMPLEX*8 Arithmetic Expression Evaluates Incorrectly

 Product Version(s): 4.10
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist4.10 fixlist5.00
 Last Modified: 16-JUN-1989    ArticleIdent: Q29565

 In some cases, when variables are declared as COMPLEX*8, arithmetic
 expressions evaluate to the wrong value.

 One way to work around the problem is to declare the variables as
 COMPLEX*16, rather than COMPLEX*8.

 The following code sample demonstrates the problem, with the suggested
 workaround in comments:

    COMPLEX*8 a,b,c

    c   This problem can be worked around by changing the above
    c   declaration to the following:
    c
    c       COMPLEX*16 a,b,c
    c
         a=(1.,0.)
         b=(0.,1.)
         write(*,'('' a ='',f10.3,1x,f10.3)') a
         write(*,'('' b ='',f10.3,1x,f10.3)') b
         c=a+(-1.0)*b
         write(*,'(''  a+(-1.0)*b=  '',2(1x,f10.3))') c
         write(*,'(''  correct answer is'',2(1x,f10.3))') (1.,-1.)
         end

 Microsoft has confirmed this to be a problem in Version 4.10; the
 problem was corrected in Version 5.00.


 318. FORTRAN: IOSTAT Returns an Invalid Run-Time Error

 Product Version(s): 4.10
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist4.10 fixlist5.00
 Last Modified: 16-JUN-1989    ArticleIdent: Q29787

 The code below will return an incorrect run-time error in "IOSTAT." To
 work around this problem, you must do one of the following:

    1. Use a temporary variable to perform the concatenation outside
       the open statement.

    2. Replace the integer variable 'long' with its numerical
       representation. Thus, the substring would look like
       'chaine(1:7)'.

    3. Define chaine as character*8 and remove substrings.

    4. Do not use substrings, leave chaine as character*80, and use
       in real mode. This workaround will not work in protected mode.

 The problem lies in the open statement. The concatenation and
 substrings inside the function cause this to fail:

       character*80 chaine
       integer ier,long
       ier = 0
       chaine = 'filename'
       long = 7
       open (unit=1,file=chaine(1:long)//'.cal',
      + status='unknown',err=10,iostat = ier)
 10    if (ier.ne.0) then
        write (*,*)'Errornumber',ier,'at opening file:',
      +    chaine (1:long)//'.cal'
        else
        write (*,*)'Correctly opened'
        write (*,*)'correctly opened'
        close(1)
        end if
        end

 Microsoft has confirmed this to be a problem in Version 4.10. This
 problem was corrected in Version 5.00.


 319. Internal Compiler Error: trees.c, Line 1165

 Product Version(s): 4.10
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist4.10 fixlist5.00
 Last Modified:  8-NOV-1989    ArticleIdent: Q29792

 The programs below generate the following errors:

    initmin.for
    initmin.for(8) : warning F4202: PRINTV : formal argument NPOINT :
                     never used
    initmin.for(6) : fatal error F1001: Internal Compiler Error
                     (compiler file '../trees.c', line 1165)
                     Contact Microsoft Technical Support

 The problems occur because the code does not conform to the ANSI 77
 Standard. Following the standard, an adjustable-size array must be
 passed as one of the arguments to the subroutine. (For more
 information on adjustable-size arrays, see Section 5.5.1 of the "ANSI
 X3.9-1978 FORTRAN 77" manual.)

 To work around this problem, pass the array VBlock to the subroutine
 along with the array index.

 Microsoft has confirmed this to be a problem in Version 4.10 of the
 FORTRAN compiler. This problem was corrected in Version 5.00.

 The following program should generate a syntax error:

    subroutine PrintVars ( inPoints )

    real VBlock ( nPoints )
    equivalence ( VBlock, S )

    call rvprint ( VBlock (nPoints) )
    return
    end

 In this case, only the array index is passed. If the program is
 changed to the following (to conform to the standard), the internal
 compiler error is not generated:

    subroutine PrintVars (VBlock, nPoints)

    real VBlock ( nPoints )

    call rvprint ( VBlock (nPoints) )
    return
    end


 320. L1103 Linker Error: Accessing Data Outside Segment Bounds

 Product Version(s): 4.01 4.10 5.00 | 4.10 5.00
 Operating System:   MS-DOS         | OS/2
 Flags: ENDUSER | buglist4.01 buglist4.10 fixlist5.00
 Last Modified:  7-NOV-1989    ArticleIdent: Q29883

 Problem:

 The following link error message occurs when I link and compile a
 large program:

    "L1103 attempt to access data outside segment bounds"

 I am compiling and linking as follows:

    fl /4I2 /FPi /c /Od /Zi program.for
    link /SE:320 /NOD /CO @program.rsp

 Response:

 You can work around this problem by changing the compile to the
 following:

     fl /4I2 /FPi /c program.for

 The generation of symbolic information may be part of the problem.

 Another workaround is to compile the different functions separately;
 doing this allows you to use CodeView and avoid the L1103 error.

 Microsoft has confirmed this to be a problem in Versions 4.01 and
 4.10 of the FORTRAN compiler. This problem was corrected in Version
 5.00.


 321. FL Automatically Adds the Extension .OBJ

 Product Version(s): 4.10   | 4.10
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | docerr
 Last Modified:  7-SEP-1988    ArticleIdent: Q29884

 Problem:

 Page 14, Section 3.6.5, of the "Microsoft FORTRAN Optimizing Compiler
 Version 4.10" update manual states that "FL automatically adds the
 extension .FOR." However, my source cannot be compiled unless I give
 the extension with the name.

 Response:

 The documentation is incorrect. The statement should read as
 follows:

 "FL automatically adds the extension .OBJ".


 322. F1901 Program Too Large for Memory on Array Initialization

 Product Version(s): 4.01 4.10
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist4.01 buglist4.10 fixlist5.00
 Last Modified:  6-NOV-1989    ArticleIdent: Q30541

 Problem:

 I have an integer*2 array of 1100 elements that is initialized in the
 source code. The total size of the array is about 4K and it is the
 only thing in the program; however, I still get the error message
 "F1901 program too big to fit in memory."

 Response:

 Microsoft has confirmed this to be a problem in Versions 4.01 and 4.10
 of the FORTRAN compiler. This problem was corrected using F1L.EXE in
 Version 5.00.

 A workaround is to declare the array in the source code and to
 initialize it by reading in the data from a file. This procedure
 allows more flexibility in changing the data. You could then just
 change the data file, instead of modifying the source, recompiling,
 and relinking.

 The following code demonstrates the problem:

       PROGRAM ESSAI
       INTEGER*2 IT0(1101)
 C===
       DATA IT0/
      -2050,2059,13,15,816,73,75,876,141,143,944,
      -203,2096,18,816,18,12,15,6565,5454,54,944,
      -2808,12,45,65,89,546,458,54,48,489,45,944,
      -2050,2059,13,15,816,73,75,876,141,143,944,
      -203,2096,18,816,18,12,15,6565,5454,54,944,
      -2808,12,45,65,89,546,458,54,48,489,45,944,
      -2050,2059,13,15,816,73,75,876,141,143,944,
      -203,2096,18,816,18,12,15,6565,5454,54,944,
      -2808,12,45,65,89,546,458,54,48,489,45,944,
      -2050,2059,13,15,816,73,75,876,141,143,944,
      -203,2096,18,816,18,12,15,6565,5454,54,944,
      -2808,12,45,65,89,546,458,54,48,489,45,944,
      -2050,2059,13,15,816,73,75,876,141,143,944,
      -203,2096,18,816,18,12,15,6565,5454,54,944,
      -2808,12,45,65,89,546,458,54,48,489,45,944,
      -2050,2059,13,15,816,73,75,876,141,143,944,
      -203,2096,18,816,18,12,15,6565,5454,54,944,
      -2808,12,45,65,89,546,458,54,48,489,45,944,
      -2050,2059,13,15,816,73,75,876,141,143,944,
      -203,2096,18,816,18,12,15,6565,5454,54,944,
      -2808,12,45,65,89,546,458,54,48,489,45,944,
      -2050,2059,13,15,816,73,75,876,141,143,944,
      -203,2096,18,816,18,12,15,6565,5454,54,944,
      -2808,12,45,65,89,546,458,54,48,489,45,944,
      -2050,2059,13,15,816,73,75,876,141,143,944,
      -203,2096,18,816,18,12,15,6565,5454,54,944,
      -2808,12,45,65,89,546,458,54,48,489,45,944,
      -2050,2059,13,15,816,73,75,876,141,143,944,
      -203,2096,18,816,18,12,15,6565,5454,54,944,
      -2808,12,45,65,89,546,458,54,48,489,45,944,
      -2050,2059,13,15,816,73,75,876,141,143,944,
      -203,2096,18,816,18,12,15,6565,5454,54,944,
      -2808,12,45,65,89,546,458,54,48,489,45,944,
      -2050,2059,13,15,816,73,75,876,141,143,944,
      -203,2096,18,816,18,12,15,6565,5454,54,944,
      -2808,12,45,65,89,546,458,54,48,489,45,944,
      -2050,2059,13,15,816,73,75,876,141,143,944,
      -203,2096,18,816,18,12,15,6565,5454,54,944,
      -2808,12,45,65,89,546,458,54,48,489,45,944,
      -2050,2059,13,15,816,73,75,876,141,143,944,
      -203,2096,18,816,18,12,15,6565,5454,54,944,
      -2808,12,45,65,89,546,458,54,48,489,45,944,
      -2050,2059,13,15,816,73,75,876,141,143,944,
      -203,2096,18,816,18,12,15,6565,5454,54,944,
      -2808,12,45,65,89,546,458,54,48,489,45,944,
      -2050,2059,13,15,816,73,75,876,141,143,944,
      -203,2096,18,816,18,12,15,6565,5454,54,944,
      -2808,12,45,65,89,546,458,54,48,489,45,944,
      -2050,2059,13,15,816,73,75,876,141,143,944,
      -203,2096,18,816,18,12,15,6565,5454,54,944,
      -2808,12,45,65,89,546,458,54,48,489,45,944,
      -2050,2059,13,15,816,73,75,876,141,143,944,
      -203,2096,18,816,18,12,15,6565,5454,54,944,
      -2808,12,45,65,89,546,458,54,48,489,45,944,
      -2050,2059,13,15,816,73,75,876,141,143,944,
      -203,2096,18,816,18,12,15,6565,5454,54,944,
      -2808,12,45,65,89,546,458,54,48,489,45,944,
      -2050,2059,13,15,816,73,75,876,141,143,944,
      -203,2096,18,816,18,12,15,6565,5454,54,944,
      -2808,12,45,65,89,546,458,54,48,489,45,944,
      -2050,2059,13,15,816,73,75,876,141,143,944,
      -203,2096,18,816,18,12,15,6565,5454,54,944,
      -2808,12,45,65,89,546,458,54,48,489,45,944,
      -2050,2059,13,15,816,73,75,876,141,143,944,
      -203,2096,18,816,18,12,15,6565,5454,54,944,
      -2808,12,45,65,89,546,458,54,48,489,45,944,
      -2050,2059,13,15,816,73,75,876,141,143,944,
      -203,2096,18,816,18,12,15,6565,5454,54,944,
      -2808,12,45,65,89,546,458,54,48,489,45,944,
      -2050,2059,13,15,816,73,75,876,141,143,944,
      -203,2096,18,816,18,12,15,6565,5454,54,944,
      -2808,12,45,65,89,546,458,54,48,489,45,944,
      -2050,2059,13,15,816,73,75,876,141,143,944,
      -203,2096,18,816,18,12,15,6565,5454,54,944,
      -2808,12,45,65,89,546,458,54,48,489,45,944,
      -2050,2059,13,15,816,73,75,876,141,143,944,
      -203,2096,18,816,18,12,15,6565,5454,54,944,
      -2808,12,45,65,89,546,458,54,48,489,45,944/
       END


 323. FORTRAN 4.10 PACKING.LST

 Product Version(s): 4.10
 Operating System:   MS-DOS
 Flags: PSSONLY | ENDUSER
 Last Modified: 30-OCT-1990    ArticleIdent: Q30570

 The following information is from the FORTRAN Version 4.10 PACKING.LST
 file:

 PACKING.LST
 for Microsoft(R) FORTRAN Optimizing Compiler Version 4.1
 (C) Copyright 1987, 1988, Microsoft Corporation

    This file describes the parts of the Microsoft(R) FORTRAN
 Optimizing Compiler Version 4.1 package.

 DOCUMENTATION
    There are three binders:

    1. Microsoft FORTRAN Optimizing Compiler Version 4.1 Update and
 Microsoft FORTRAN Optimizing Compiler User's Guide
    2. Microsoft FORTRAN Optimizing Compiler Language Reference
    3. Microsoft CodeView(R) and Utilities and Microsoft Editor

    The package also includes a quick reference guide and templates:

    Microsoft FORTRAN Optimizing Compiler Quick Reference Guide
    Two function-key templates for the Microsoft CodeView debugger

 DISKS
    The Microsoft FORTRAN compiler is distributed on ten 5-1/4" disks
 or five 3-1/2" disks. The 3-1/2" disks are not included in this
 package. To obtain 3-1/2" disks, telephone Microsoft Sales and Service
 at (800) 426-9400. Please have your manuals handy when you call.
    The following two lists describe the layout of the 5-1/4" disks and
 show how the contents of the 5-1/4" disks are combined to make up the
 3-1/2" disks.

 5-1/4" Disk Layout

      Disk 1:  Setup

           DEMOS    <DIR>
           PATCH    <DIR>
           EMOEM.ASM      MASM source to modify 87.LIB for
                          non-IBM(R) compatibles
           F3S.EXE        FORTRAN compiler, Pass 3, small model (non-optimized
           FL.ERR         Error message file for FL.EXE
           FL.EXE         FORTRAN compiler driver
           FL.HLP         Help file for FL.EXE
           FLOPSET.DOC    Floppy disk set up documentation
           PACKING.LST    Packing list (this file)
           PATCH87.EXE    MS-DOS 3.2 Patch program
           README.DOC     Information made available after manuals
                          were printed
           SETUP.DAT      Data file for SETUP program
           SETUP.EXE      FORTRAN SETUP program

                 (13 files)

           \DEMOS subdirectory (Demonstration Programs)

           CIRC.C         C-module for GRAPH.EXE program
           DEMO.FOR       FORTRAN demo program
           DEMOEXEC.FOR   FORTRAN demo program (calling a C procedure)
           DEMORAN.FOR    FORTRAN demo program (random number generator)
           DWHET.FOR      Popular benchmark program
           FOREXEC.INC    FORTRAN demo program (include file)
           GRAPH.BAT      Batch file for GRAPH.EXE file
           GRAPH.FOR      FORTRAN module for GRAPH.EXE program
           SECNDS.FOR     Subroutine for benchmarks
           SIEVE.FOR      Popular benchmark program
           SWHET.FOR      Popular benchmark program

                 (11 files)

           \PATCH subdirectory (PC-DOS 3.2 patch):

           README.DOC
           RMRHS.EXE
           SETRHS.EXE
           STKPAT.BAT
           STKPAT.SCR

                 (5 files)

      Disk 2:  Compiler 1

           F1.ERR         Error message files for compiler, Pass 1
           F1.EXE         FORTRAN compiler, Pass 1
           F3.EXE         FORTRAN compiler, Pass 3

                 (3 files)

      Disk 3:  Compiler 2

           EXEC.EXE       Utility used only by ILINK
           F2.EXE         FORTRAN compiler, Pass 2
           F23.ERR        Error messages for FORTRAN compiler,
                          Passes 2 and 3
           ILINK.EXE      Microsoft Incremental Linker
           LIBBUILD.BAT   Combined library builder

                 (5 files)

      Disk 4:  Utilities

           BIND.EXE       Operating System/2 BIND Utility
           ERROUT.EXE     STDERR Redirection Utility
           EXEHDR.EXE     Segmented EXE Header Utility
           EXEMOD.EXE     EXE File Header Utility
           EXEPACK.EXE    EXE File Compression Utility
           IMPLIB.EXE     Import Library Manager
           LIB.EXE        Library Manager
           LINK.EXE       Segmented-Executable Linker
           MAKE.EXE       Program Maintenance Utility
           SETENV.EXE     Environment Expansion Utility

                 (10 files)

      Disk 5:  Microsoft CodeView(R) for MS-DOS(R)

           DEMO.BAT       CodeView debugger demonstration file
           MOUSE.COM      Mouse driver
           C_AUTO.CV      CodeView debugger demonstration file
           E_AUTO.CV      CodeView debugger demonstration file
           L_AUTO.CV      CodeView debugger demonstration file
           M_AUTO.CV      CodeView debugger demonstration file
           Q_AUTO.CV      CodeView debugger demonstration file
           S_AUTO.CV      CodeView debugger demonstration file
           IN.DAT         Data file used with STATS.FOR
           CVREADME.DOC   Information about CodeView/Utilities
                          made available after manuals were printed
           CV.EXE         CodeView debugger
           WHAT.EXE       Program used by CodeView demo
           STATS.FOR      FORTRAN program used in CodeView demo
           CV.HLP         CodeView debugger help file

              (14 files)

      Disk 6:  Microsoft CodeView for OS/2

           CVP.EXE        OS/2 CodeView debugger
           CVP.HLP        OS/2 CodeView help file
           CVPACK.EXE     Debugging information packing utility
           MAKESORT.BAT   DOS batch file for SORTDEMO.FOR
           MAKESORT.CMD   OS/2 batch file for SORTDEMO.FOR
           OS2PATCH.EXE   OS/2 patch utility
           PTRACE87.PAT   Patch file for OS2PATCH.EXE
           SORTDEMO.FOR   OS/2 demonstration file

              (8 files)

      Disk 7:  Libraries (Large Model)

           87.LIB         8087/80287 math library (model independent)
           ALTMATH.LIB    Large-model FORTRAN 3.3x-compatible alternate math
                          library
           EM.LIB         Emulator library (model independent)
           FORTRAN.LIB    Large-model FORTRAN 3.3x-compatible library
           LCLIB1.LIB     Large-model DOS 3 C library
           LIBH.LIB       Helper library (model independent)
           LLIBFA.LIB     Large-model alternate-math library
           LLIBFOR.LIB    Large-model standard FORTRAN library
           LLIBFOR1.LIB   Large-model DOS 3 FORTRAN library
           LLIBFP.LIB     Large-model floating-point math library
           MATH.LIB       Large-model FORTRAN 3.3x math compatibility library
           NBUILD.OBJ     Error-message stub file (model independent)

                 (12 files)

      Disk 8 of 10:  Libraries (Medium Model)

           87.LIB         8087/80287 math library (model independent)
           EM.LIB         Emulator library (model independent)
           LIBH.LIB       Helper library (model independent)
           MCLIB1.LIB     Medium-model DOS 3 C library
           MLIBFA.LIB     Medium-model alternate math library
           MLIBFOR.LIB    Medium-model standard FORTRAN library
           MLIBFOR1.LIB   Medium-model DOS 3 FORTRAN library
           MLIBFP.LIB     Medium-model floating-point math library
           NBUILD.OBJ     Error-message stub file (model independent)

                 (9 files)

      Disk 9 of 10:  MS OS/2 Libraries

           STARTUP  <DIR>
           API.LIB        Family API emulation library
           APILMR.OBJ     64K stack object file (for use with BIND)
           DOSCALLS.LIB   Import library for API
           LCLIB2.LIB     Large-model OS/2 C library
           LLIBFOR2.LIB   Large-model OS/2 FORTRAN library
           MCLIB2.LIB     Medium-model OS/2 C library
           MLIBFOR2.LIB   Medium-model OS/2 FORTRAN library

                 (8 files)

           \STARTUP subdirectory (startup source code):

           DOS      <DIR>
           OS2      <DIR>
           BRKCTL.INC
           CHKSTK.ASM
           CHKSUM.ASM
           CMACROS.INC
           CRT0FP.ASM
           MAKEFILE
           MSDOS.INC
           NULBODY.FOR
           ONEXIT.ASM
           README.DOC
           STARTUP.BAT
           VERSION.INC

                 (14 Files)

           \STARTUP\DOS subdirectory (DOS-specific startup source code):

           CRT0.ASM
           CRT0DAT.ASM
           CRT0MSG.ASM
           NMSGHDR.ASM
           NULBODY.LNK
           STDALLOC.ASM
           STDARGV.ASM
           STDENVP.ASM

                 (8 Files)

           \STARTUP\OS2 subdirectory (OS\2-specific startup source code):

           CRT0.ASM
           CRT0DAT.ASM
           CRT0MSG.ASM
           EXECMSG.ASM
           NMSGHDR.ASM
           NULBODY.LNK
           STDALLOC.ASM
           STDARGV.ASM
           STDENVP.ASM

                  (9 Files)

      Disk 10:  Microsoft Editor

           INI      <DIR>
           MSETUP.BAT     Installation and setup routine
           FIXSHIFT.COM   Keyboard driver patching utility
           ECH.EXE        Character echoing utility used by Microsoft Editor
           EXP.EXE        Expunge utility (used with RM)
           M.EXE          Microsoft Editor
           MEGREP.EXE     Pattern finding utility (GREP)
           MEP.EXE        OS/2 Microsoft Editor
           RM.EXE         File removing utility
           UNDEL.EXE      File undeletion utility (used with RM)
           WHAT.EXE       Program used by MSETUP

                  (11 Files)

           \INI subdirectory (Initialization files for Microsoft Editor):

           BRIEF.INI      BRIEF(R) initialization file
           EPSILON.INI    Epsilon(TM) initialization file
           QUICK.INI      Quick-product initialization file
           WS.DLL         Protected-mode extension file
           WS.ZXT         Real-mode (DOS) extension file

                  (5 Files)

 3-1/2" Disk Layout
    The five 3-1/2" disks combine the 5-1/4" disks as follows:

      Disk 1:  Setup / Compiler 1
      Disk 2:  Compiler 2 / Utilities
      Disk 3:  Microsoft CodeView for MS-DOS / Microsoft CodeView for OS/2
      Disk 4:  Libraries (Large and Medium Models)
      Disk 5:  MS OS/2 Libraries / Microsoft Editor


 324. __Flclenv Should be __FCclenv

 Product Version(s): 4.00 4.01 4.10 | 4.10
 Operating System:   MS-DOS         | OS/2
 Flags: ENDUSER | docerr
 Last Modified: 15-JUN-1988    ArticleIdent: Q30588

    There are three references to a global variable named "__FIclenv"
 on Page 261 of the "Microsoft Fortran Optimizing Compiler User's
 Guide."
    These references are incorrect; the correct name is "__FCclenv".


 325. Compile-Time Fatal Error F1914 Occurs When Using FORTRAN

 Product Version(s): 4.00 4.01 4.10 5.00 | 4.10 5.00
 Operating System:   MS-DOS              | OS/2
 Flags: ENDUSER |
 Last Modified: 26-JUL-1990    ArticleIdent: Q30589

 The "F1914 cannot open internal files" compile-time fatal error
 message may appear when you use Microsoft FORTRAN.

 This error occurs if you improperly set your environment. Your
 AUTOEXEC.BAT and CONFIG.SYS files must have the correct syntax; there
 should be no spaces in the settings with the exception of a space
 between SET and the particular variable being set.

 For example, the variable setting PATH = C:\DOS (note the spaces
 around the equals sign) must be changed to PATH=C:\DOS.

 FILES = 20 must be changed to FILES=20. In addition, there should be
 no space or hidden characters at the end of a line such as SET
 TMP=C:\TMP.

 The F1914 error also can occur if the specified directory does not
 exist. For example, the environment variable setting SET TMP=C:\TEMP
 is incorrect if C:\TEMP does not exist. Misspelling C:\TMP as C:\TEMP
 can cause this error.

 If there is no room on the disk for a file to be created, the F1914
 error occurs. This error can occur if a RAM drive is being used for
 the TEMP subdirectory. If the RAM drive is set too small or set
 incorrectly, error F1914 can be generated.


 326. Global Array Pointed to by __FCclenv

 Product Version(s): 4.00 4.01 4.10 | 4.10
 Operating System:   MS-DOS         | OS/2
 Flags: ENDUSER | __FCclenv global array
 Last Modified: 19-SEP-1988    ArticleIdent: Q34972

 Question:

 What is exactly pointed to by the global variable __FCclenv in
 FORTRAN? I see it referenced on Page 261 of the "Microsoft FORTRAN
 Optimizing Compiler User's Guide," but I don't understand what is
 being stored.

 Response:

 The __FCclenv global variable contains the address to an array that
 contains the lengths of character arrays that are being passed to a
 FORTRAN subroutine or function. The compiler must keep track of the
 actual lengths of the character arrays, whether the arrays are varying
 or not, thus storing the information in this global array.

 The first element of this global array will contain the length of the
 character array for the return value of a character function. If the
 function returns anything other than a character array, or is a
 subroutine, the first value will contain whatever happens to be at the
 particular memory location (i.e., meaningless information). Consider
 the following two examples:

 character*80 function junk(a,b,c,d,e,f,g)
 character*(*) a,b,c,e,f,g
 character*4 d

 This declaration will put 80 in the first element of the global array
 pointed to by __FCclenv. This will be followed by the lengths of the
 arrays of a, b, c, d, e, f, g.

 subroutine junk(a,b,c,d,e,f,g)
 character*(*) a,b,c,e,f,g
 character*4 d

 This declaration will put nothing in the first element (so the memory
 location for this first element will be whatever value happens to be
 at that location). The remaining elements will contain the lengths of
 the passed arrays. This will also hold true for other functions that
 return values other than characters.


 327. NonPrintable Characters in Source File

 Product Version(s): 4.00 4.01 4.10
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified:  9-JUN-1988    ArticleIdent: Q31022

    Page 13 of the FORTRAN Versions 4.00 and 4.10 Optimizing Compiler
 reference manual (section 2.2) states the following:

    "Microsoft FORTRAN source files can contain any PRINTABLE
 characters in the ASCII character set."

    This sentence in the manual is indicated to be an extension because
 the standard itself does not permit lowercase letters.
    Embedded control characters in source files generally are used to
 either control the screen cursor or a printer, or send a "beep" to the
 screen. You can do any of these without embedding control characters.
    For example, to send a message ending with a "beep" to the
 terminal, write the following:

    CHARACTER OUTSTR*20
    OUTSTR = 'This is the message'
    OUTSTR(20:20) = CHAR(7)
    WRITE (*,*) OUTSTR
    END

    This code conforms to the ANSI X3.9-1978 FORTRAN standard, so it
 will run on all standard conforming compilers. With this example, you
 can substitute any of the ASCII characters (i.e., CHAR(0) to
 CHAR(255)).
    However, the same is not true if you try to embed the character in
 the string itself.

    While some characters, such as BEL (CHARACTER(7)), may produce the
 desired results when embedded in a character string, others, e.g. NUL
 (CHAR(0)), CTRL-Z (CHAR(26), and BS (CHAR(8)), may cause unexpected
 behavior.
    The use of nonprintable ASCII characters embedded in source files
 is not supported. The same results can be achieved by using the CHAR
 function to insert the characters in their proper place at run time by
 either using character substrings or the // concatenation operator.
    The following is a source line that causes the error "F2031:
 closing quote missing":

    80 SUPB = '\033S\000\010'

    The following four characters were present in "SUPB" to change the
 printer to bold superscripting:

    1. ESC (hex 1B)
    2. "S"
    3. NUL (hex 00)
    4. BS (hex  08)

    This attempt has several flaws; it is nonportable, and both
 compiler and editor dependent.
    There are several more-preferable ways to do this, using either
 portable or nonportable features. Using standard features, the line
 could be rewritten as follows:

    80 SUPB = CHAR(27) // 'S' // CHAR(0) // CHAR(8)

    If the nonprintable characters have been defined individually as
 character variables, the line could be rewritten as follows:

    80 SUPB = ESC // 'S' // NUL // BS

    If you want to be nonstandard, the line could be rewritten as
 follows:

    80 SUPB = #1B530008



 328. How CTRL-Z Is Interpretted for Various File Types

 Product Version(s): 3.20 3.30 3.31 3.32 4.00 4.01 4.10
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified:  9-JUN-1988    ArticleIdent: Q31023

    The following list demonstrates the various file types, and whether
 or not an embedded CTRL-Z is allowed:

                         Embedded
                         CTRL-Z
 File Type               Allowed         Notes

 Binary                  Yes             Read or write; no restriction.
 Unformatted             Yes             Read or write; no restriction.
 Formatted               No (not on read)
                                         Trailing CTRL-Z and NULL (0)
                                         characters are stripped off.
                                         You can write CTRL-Z (using CHAR(26))
                                         into a file, but unless you are
                                         reading a character variable, you
                                         will get a run-time error if a
                                         CTRL-Z is found.
                                         A text file should not have
                                         any non-printable characters
                                         in it.

 Internal                No (not on read)



 329. Real*8 or Double Precision Must Contain an Exponent

 Product Version(s): 4.00 4.01 4.10
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 12-JUL-1988    ArticleIdent: Q31173

    When using real*8 or double-precision variables, the FORTRAN manual
 says the variables should be significant to 15 digits. However, these
 variables use only the first seven digits correctly; the remaining
 eight digits are used randomly.
    To get 15 digits of precision into your real*8 variables, you must
 declare the constant with an exponent. If the exponent is omitted, the
 number is interpreted as a single-precision constant.
    For more information, please refer to the "Microsoft FORTRAN
 Optimizing Compiler Language Reference" manual, Section 2.4.3, Pages
 23-24.

    The following is a code example of the proper way to set a
 double-precision variable with the D:

          real*8 doub_real
    c      double precision doub_real
    c      either real*8 or double precision needs to use the D.

          doub_real = .55555555555555555555D0
          print '(f20.18)',doub_real
          end


 330. $DECLARE Fails on Nondeclared Argument-List Variables

 Product Version(s): 4.10
 Operating System:   MS-DOS
 Flags: ENDUSER | Buglist4.1
 Last Modified: 16-JUN-1988    ArticleIdent: Q31320

    The $DECLARE metacommand does not generate a compile-time warning
 when a variable appearing in the argument list of a subroutine is used
 without being typed.
    The following code sample does not warn that "A" is undeclared, but
 it should generate a compile-time warning:

    $DECLARE
             SUBROUTINE POOT(A)
             A=1.0
             RETURN
             END

    Microsoft has confirmed this to be a problem with Microsoft FORTRAN
 Version 4.10.
    Microsoft is researching this problem and will post new information
 as it becomes available.


 331. Passing Function Names as Arguments to NonFORTRAN Routines

 Product Version(s): 4.10
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 16-JUN-1988    ArticleIdent: Q31322

    FORTRAN procedural arguments are not compatible with C-procedure
 pointers ( e.g. you cannot pass function names as arguments to C
 routines). Because FORTRAN treats function pointers differently then
 other pointers, the C routines do not "understand" what is being passed
 to them.
    For more information on this subject, please see Pages 287-288
 (Section 11.3.8.6) and Page 293 (Section 11.3.8.9) in the "Microsoft
 FORTRAN Optimizing Compiler User's Guide."


 332. Appending to a File

 Product Version(s): 3.x 4.00 4.01
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified:  8-MAR-1988    ArticleIdent: Q11271

 Problem:
    Under mainframe FORTRAN there is a function MOD; it adds data to
 the end of a file in FORTRAN. I cannot find a similar
 command in your compiler. I want to add some data to
 the end of an ASCII file.
    I have used the command ENDFILE as an example to solve the problem.
 However, a sequential file that is opened and written to will
 overwrite the existing data (as stated in the manual).

 Response:
    On Pages 15-23 and 15-23s of the ANSI FORTRAN standard (ANSI
 X3.9-1978, which both mainframe and microcomputers follow), in the
 section concerning functions and subroutines, a MOD function is
 described that is used for remaindering, not for appending data to a
 file.
    The only function we are aware of that you may be thinking of is
 the specifier that some FORTRANs have added to the OPEN statement for
 example, ACCESS=APPEND. However, this is not part of the ANSI
 standard.
    At any rate, there is no mechanism in the ANSI standard to append
 to the end of files, and we have not added one. The only way to append
 to the end of a file is to do the following:

    1. Read from an old file.
    2. Write to a new file.
    3. Repeat (1) and (2) until reaching end-of file on the old file.
    4. Write new information to the new file.


 333. Incorrect Expression Evaluation

 Product Version(s): 3.31
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 12-MAY-1988    ArticleIdent: Q11347

 Problem:
    The expression '(I - 1) * 256' is not being evaluated correctly.
    When $STORAGE:2 and $DEBUG metacommands are used and I is given the
 value 128, an integer overflow error occurs.
    The following code example demonstrates this behavior:

       $STORAGE:2
       $DEBUG
       PROGRAM TEST
       I = 128
       J = (I - 1) * 256
       END

 Response:
    Microsoft confirmed this to be a problem in Version 3.31 of the
 FORTRAN compiler.
    This problem was corrected in Version 4.00.


 334. Problem Assigning Format Label

 Product Version(s): 3.31
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist3.31 fixlist4.00
 Last Modified: 20-OCT-1988    ArticleIdent: Q11356

 Problem:

 There is a problem associated with assigning a format label to an
 integer variable using the ASSIGN statement, then using the format
 label more than once in a WRITE statement.

 The following is a code sample that reproduces this behavior:

        PROGRAM TEST
        ASSIGN 4 TO I
        WRITE(*,4)' HELLO'
        WRITE(*,4)' HELLO' 4 FORMAT(A6)
        END

 Response:

 Microsoft confirmed this to be a problem in Version 3.31 of the
 FORTRAN compiler. This problem was corrected in Version 4.00.


 335. Incorrect Code Generated when Passing the Same Argument Twice

 Product Version(s): 4.10 5.00
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist4.10 fixlist5.00
 Last Modified:  7-NOV-1989    ArticleIdent: Q31420

 The following program generates bad code when compiled with
 optimization on; it works correctly when compiled with -Od:

 C     Beginning of program
       call sub(i, i)
       end
 C--------------------------
       subroutine sub(i, j)
       i=17
       j=44
       write(*, *) i, j
       return
       end

 Because FORTRAN is passed by reference, this program should print out
 "   44    44   ". This is the result with optimization off; however,
 the result is "  17    44   " when the optimization is turned on.

 This problem occurs when the optimizer is on because it forces
 incorrect mov instructions, which causes a "pass by value" result.

 Microsoft has confirmed this to be a problem in FORTRAN Version 4.10.
 This problem was corrected in Version 5.00.

 The following assembly code was taken from an assembly dump of the
 program above.  This fragment comes after the initialization of I
 and J and before the CALL to __FFwr ( write function ):

 Optimization off:                       On:
 ( moves address )                       ( moves value )

 les   bx, dword ptr [bp+6]              mov ax, 44
 push  word ptr es:[bx+2]                cwd
 push  word ptr es:[bx]                  push dx
 ;                                       push ax
 ;
 les   bx dword ptr [bp+10]              mov  ax, 17
 push  word ptr es:[bx+2]                cwd
 push  word ptr es:[bx]                  push dx
                                         push ax

 The following command line was used:

    FL -AL -FPi -Zi -Fs -Fa -O? test.for.


 336. Carriage-Control Character Not Recognized

 Product Version(s): 4.00
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist4.00 fixlist4.01
 Last Modified: 16-JUN-1988    ArticleIdent: Q31421

    The carriage-control character, '1', is not recognized as a
 carriage-control character and is printed out as the character one.
    In the following example program, using the format specifier 'Nx'
 in a previous FORMAT edit list causes subsequent formatting to be
 corrupted. The string output is unexpectedly moved to the right by N
 spaces, and so the carriage-control character is not in position to be
 used by the printer.
    A workaround is to use the edit decriptor for end-of-record, '/',
 in the first position in the subsequent FORMAT's editlist.
    This is a known problem with Version 4.00. This problem was
 corrected in Version 4.01.

    The following is the example program:

       CHARACTER*72 RFMT,TITLE
       OPEN(5,FILE='TRY.INP')
       OPEN(6,FILE='PRN')
       READ(5,5)RFMT
     5 FORMAT(A)
       READ(5,5)TITLE
     1 READ(5,RFMT,END=3)X,Y
       GO TO 1
     3 WRITE(6,9)TITLE
     9 FORMAT('1',A)
       WRITE(6,2)X,Y
     2 FORMAT('-','X IS',F15.5/
      1     '-','Y IS',F15.5)
       STOP
       END

    The input file contains the following:

 (5x,f5.1,6x,f6.0)
 titlestring
   5.7  6.9  3797 36778
   6.5  6.9  4099 36588

    The output on the printer appears as follows:

      1titlestring
 X IS        6.90000
 Y IS    36588.00000

    The workaround statement is to replace the following FORMAT line:

    9 FORMAT('1',A)

    with the following:

    9 FORMAT(/'1',A)

    This process will produce the correct output, as follows:

 titlestring
 X IS        6.90000
 Y IS    36588.00000


 337. Logical Expressions in Parameter List

 Product Version(s): 3.31
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist3.31
 Last Modified: 12-MAY-1988    ArticleIdent: Q11584

 Problem:
    There is an inconsistency in the way the compiler evaluates logical
 expressions when they are used as parameters in a function call.
    Specifically, if a logical expression involving a real number is
 used as a parameter in a function call, it is not properly evaluated
 before being passed to the function.
    The following is a program that demonstrates this behavior:

    integer iso
    real riso
    logical chkr,t1,t2
    iso=45
    riso=45.0

    if (chkr(.TRUE.,(riso.ge.0.0), (riso.lt.180.0))) then
    write(*,*) 'real true'
    else
    write(*,*) 'real false'
    endif

    t1=(riso.ge.0.0)
    t2=(riso.lt.180.0)
    if (chkr(.TRUE.,t1,t2)) then
    write(*,*) 'real true'
    else
    write(*,*) 'real false'
    endif

    stop
    end

    logical function chkr(b1,b2,b3)
    logical b1,b2,b3

    chkr=(b1.and.b2.and.b3)
    if (chkr) return
    write(*,*) 'error'
    return
    end

 Response:
    Microsoft confirmed this to be a problem in Version 3.31 of the
 FORTRAN compiler.
    This problem was corrected in Version 4.00.


 338. Problem with LLE()

 Product Version(s): 3.31
 Operating System:   MS-DOS
 Flags: enduser | buglist3.31
 Last Modified:  2-MAY-1988    ArticleIdent: Q11583

 Problem:
    The function LLE() does not handle the characters "z" and "Z"
 correctly if they are embedded in a string. If the function is given
 two single characters to compare, it will return the correct value.

 Response:
    Microsoft confirmed this to be a problem in Version 3.31 of the
 FORTRAN compiler. The problem was corrected in Version 4.00.


 339. C Attribute on Named Common

 Product Version(s): 3.30
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 12-MAY-1988    ArticleIdent: Q11664

 Problem:
    The C attribute on a named common apparently has no effect. Because
 of this limitation, you must actually call a FORTRAN routine to access
 FORTRAN common from a C program. This will return a pointer to the first
 element in common.
    The following is a code sample that demonstrates this behavior:

    subroutine test
    common/stmt [C]/j(3)
    j(1)=3
    j(2)=5
    j(3)=8
    stop
    end

 Response:
    You can work around this problem by using the "ALIAS" attribute,
 which gives your variable a lowercase name preceded by an underscore.
 The following is an example:

    SUBROUTINE TEST
    COMMON /STMT [ alias:'_stmt' ] / j(3)
    j(1)=3
    j(2)=5
    j(3)=8
    STOP
    END

    Microsoft confirmed this to be a problem in Version 3.30 of the
 FORTRAN compiler.
    The problem was corrected in Version 3.31.


 340. Logical*1 Arrays Written Incorrectly

 Product Version(s): 4.00 4.01
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist4.01
 Last Modified: 31-MAY-1988    ArticleIdent: Q26267

 Problem:
    The following program :

         LOGICAL*1 TBP(8)
         OPEN(1,FILE='B',STATUS='OLD')
         READ(1,*)TBP
         WRITE(*,*)TBP
         WRITE(*,*)TBP(1),TBP(2),TBP(3),TBP(4),TBP(5),TBP(6),TBP(7),TBP(8)
         REWIND(1)
         READ(1,*)TBP(1),TBP(2),TBP(3),TBP(4),TBP(5),TBP(6),TBP(7),TBP(8)
         WRITE(*,*)TBP
         WRITE(*,*)TBP(1),TBP(2),TBP(3),TBP(4),TBP(5),TBP(6),TBP(7),TBP(8)
         END

 produces the following output:

         F F F F F F F F
         F F F F F F F F
         T T T T T T T T
         T T T T F T T F

    Only the last line of the output is correct.

 Response:
    Changing the logical*1 declaration to logical*2 produces correct
 output for all write statements.
    Microsoft is researching this problem and will post new information
 as it becomes available.


 341. Syntax Errors Hang Compiler

 Product Version(s): 4.x
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist4.01
 Last Modified: 31-MAY-1988    ArticleIdent: Q26268

 Problem:
    The following program issues the expected messages for the syntax
 errors, then the compiler hangs:

               IF (I) THEN
                 X=0
               ELSE IF (I.GT.0) THEN
                 X=1
               ENDIF
               IF (I.EQ.0) THEN
                X=0.
               ELSE IF (I) THEN
                X=1.
               ENDIF
               END

 Response:
    Microsoft is researching this problem and will post new information
 as it becomes available.


 342. FORTRAN: /4Yb Switch Causes F2367 Range Error

 Product Version(s): 4.01 4.10
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist4.01 buglist4.10
 Last Modified: 16-JUN-1989    ArticleIdent: Q31422

 Compiling with the /4Yb debug switch causes the following error:

    F2367 : value nnnnn : INTEGER : range error

 This error occurs when the high order (sign) bit is set, i.e., for
 values between -32768 (#8000) to -1 (#FFFF) ), as follows:

       integer*2 i

       i = #7fff          OK
       i = #8000          Fails with /4Yb switch
       i = #ffff          Fails with /4Yb switch

 The compiler is not performing the correct conversion from an unsigned
 hexadecimal value to a signed decimal value when the /4Yb switch is
 used.

 This is a known problem with the FORTRAN compiler Versions 4.01 and
 4.10. Microsoft is researching this problem and will post new
 information as it becomes available.


 343. FORTRAN: Internal Compiler Error: ctypes.c 1.89, Line 428

 Product Version(s): 4.10
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist4.10 fixlist5.00
 Last Modified: 16-JUN-1989    ArticleIdent: Q31483

 The program below will cause the following error when compiled with FL
 /Od LINE482.FOR.:

 line482.for
 line482.for(18) : fatal error F1001: Internal Compiler Error
                 (compiler file '@(#)ctypes.c:1.89', line 428)
                 Contact Microsoft Technical Support

 The program below should not generate the internal compiler error.
 However, the program code is incorrectly passing the wrong type of
 arguments to connect.

 To work around this problem, declare "x" and "y" as characters and
 initialize them as such. This will prevent the internal compiler error
 and allow the function to execute properly. Use the EQUIVALENCE
 function if you want to access the variables in different ways.

 Microsoft has confirmed this to be a problem in Version 4.10 of the
 FORTRAN compiler. This problem was corrected in Version 5.00.

 The program code is as follows:

     interface to integer*2 function connect[pascal](c,l)
       character*40 c, l
       end

       integer*2 connect, x, y, s
       x = 1
       y = 2
       s = connect(x,y)

       end


 344. Bound Programs in DOS Version 2.x Give Error SYS 2090

 Product Version(s): 4.10
 Operating System:   MS-DOS
 Flags: ENDUSER | s_c h_masm s_pascal
 Last Modified: 23-JUN-1988    ArticleIdent: Q31499

    Bound programs generate the following error under DOS Version 2.x
 when that program does not reside in the current directory:

    SYS2090: The system is unable to load the program

    The workaround is to make sure that the following programs reside
 in the current working directory, or to switch over to DOS Version
 3.x. Make certain that that if you are using DOS Version 3.x , your
 version of COMMAND.COM reported by "command" matches your version of
 DOS reported by "ver".
    Microsoft is researching this problem and will post new information
 as it becomes available.

    This error is generated even if the full drive path of the program
 is given or if the program is in a directory that is in the PATH.
 These programs include the FORTRAN compiler Version 4.10, the PASCAL
 compiler Version 4.00, and bound versions of the following utilities
 that are packaged with C Version 5.10, MASM Version 5.10, FORTRAN
 Version 4.10, and Pascal Version 4.00:

      SETUP.EXE
      CREF.EXE
      CVPACK.EXE
      MAKE.EXE
      LIB.EXE
      EXEHDR.EXE
      LINK.EXE
      IMPLIB.EXE
      BIND.EXE


 345. FORTRAN: WRITE to Screen Truncates String in 4.10

 Product Version(s): 4.10
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist4.10 fixlist5.00
 Last Modified: 16-JUN-1989    ArticleIdent: Q31513

 The following code demonstrates an error in the FORTRAN Version 4.10
 compiler. A subroutine called prior to a WRITE statement fails to
 correctly process a character string unless a WRITE statement is
 present before a certain assignment in the subroutine, or optimization
 is turned off (/Od).

 Microsoft has confirmed this to be a problem in Version 4.10 of the
 FORTRAN compiler. This problem was corrected in Version 5.00.

 The following program demonstrates a problem with the FORTRAN
 compiler. The routine should print "N7A", but does not do so unless
 the WRITE statement in the subroutine below is installed, or /Od is
 used:

        IMPLICIT INTEGER (A-Z)
        DIMENSION WIN(4)
        DATA WIN/'N','7','A',' '/
        DATA BLANK/' '/
 C
        WOUT=BLANK
        DO 2 I=1,4
        CALL BYTE2(WIN(I),1,WOUT,I)
      2 CONTINUE
        WRITE(*,'(A,A4,A)') ' ** BYTE2:''',WOUT,''''
        STOP
        END
 ***********************************************************************
 ***********************************************************************
       SUBROUTINE BYTE2(WIN,INBYT,WOUT,IOBYT)
       IMPLICIT INTEGER (A-Z)
       CHARACTER*1 AIN,AOUT
       DIMENSION AIN(4),AOUT(4)
       EQUIVALENCE (AIN,XIN),(AOUT,XOUT)
 c
       XIN=WIN
       XOUT=WOUT
 C     WRITE(5,'(1x,a4)')wout
 C  Reinstalling the above WRITE statement corrects the problem.
       AOUT(IOBYT)=AIN(INBYT)
       WOUT=XOUT
       RETURN
       END


 346. L2029 "Unresolved Externals" Error in FORTRAN Library

 Product Version(s): 4.00 4.01 4.10
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 23-JUN-1988    ArticleIdent: Q31577

    It is likely that the FORTRAN libraries were built with C
 compatibility if many type L2029 "unresolved externals" errors occur
 on names beginning with an underscore when linking a FORTRAN program.
    A problem will occur when the FORTRAN library is built with C
 compatibility and the C libraries are not also linked in. This problem
 will occur even if no C modules, only FORTRAN modules, are linked in.
    When a FORTRAN library is set up to be C compatible, the routines
 that are in common between C and FORTRAN are removed from the FORTRAN
 library. The user must link with the C libraries each time to make
 those routines available to the linker, even if only FORTRAN modules
 are being linked in.
    This error also will occur if the linker being used is not the
 latest version; it also can be caused by TSR interference. When these
 two common reasons for the L2029 error are eliminated, check the
 libraries to see if they contain the module that is unresolved. This
 can be done with the library manager LIB.EXE file.


 347. Carriage-Control Processing only on Terminal Files

 Product Version(s): 4.10
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified:  4-NOV-1988    ArticleIdent: Q37543

 Carriage-control processing is only performed on terminal files, i.e.,
 screen and printer files (LPT1). Therefore the following code will not
 process the carriage-control character:

       character*6 b
       integer c(31)
       open(unit=11,file='LPT2',form=formatted,status=new,iostat=ios);
       write(11,1,iostat=ios) b,c
 1     format('+',a,31a4)

 The '+' is printed out to LPT2 as a character instead of carriage
 control for printing. This is because LPT2 is not a terminal file.


 348. Linking FORTRAN and C, "L2044 _FF_MsgBanner Multiply Defined"

 Product Version(s): 4.00 4.01
 Operating System:   MS-DOS
 Flags: ENDUSER | S_C 5.00 5.01
 Last Modified: 20-APR-1989    ArticleIdent: Q31609

 Problem:

 When linking FORTRAN and C modules, I receive the error "L2044
 _FF_MsgBanner Symbol Multiply Defined." I have set up FORTRAN for C
 compatibility and I am linking with the /NOE switch.

 Response:

 When using FORTRAN Version 4.00 or 4.01 with C 5.00 or C 5.10, you
 need to run the F4COMPAT file to make your FORTRAN libraries C
 compatible because FORTRAN Versions 4.00 and 4.01 were written in C
 Version 4.00.

 If the /NOD switch is used, altering the order of the libraries may
 change the error message received. When the FORTRAN library is first,
 the error may be "R6002 Floating Point Not Loaded." When the C library
 is first, the error is "Symbol Multiply Defined."


 349. Infinite Loop and Protection Violation Error in FORTRAN 4.x

 Product Version(s): 4.00 4.01 4.10 5.00 | 4.10 5.00
 Operating System:   MS-DOS              | OS/2
 Flags: ENDUSER | buglist4.00 buglist4.01 buglist4.10 fixlist5.00
 Last Modified:  7-NOV-1989    ArticleIdent: Q31649

 The following code will repeatedly loop when compiled and executed in
 real mode with FORTRAN 4.00, 4.01, or 4.10. In OS/2, this code
 produces a protection violation during compile time.

 The workaround is to compile with either /Od or /Odct.

 Microsoft has confirmed this to be a problem in the FORTRAN compiler
 Versions 4.00, 4.01, and 4.10. This problem was corrected in Version
 5.00.

 The following code demonstrates the problem:

        DATA LIMIT/57/, JUMP/14/
 C
   110  FORMAT(4I12)
        PAUSE 0
        DO 120 KOUNT = 1, LIMIT, JUMP
   120  WRITE(*,110) KOUNT, LIMIT, JUMP
        PAUSE 'DO-loop done'
        LOOP = JUMP
   130  WRITE(*,110) LOOP
        LOOP = LOOP - 1
        IF (LOOP .GT. 0) GOTO 130
        PAUSE 'GOTO-loop done'
        DO 140 KOUNT = 1, LIMIT, JUMP
   140  WRITE(*,110) KOUNT, LIMIT, JUMP
        PAUSE 'DO-loop done'
        WRITE(*, '(/'' Do we see this message???'')')
   150  END

 The line "Do we see this message???" appears only when this code is
 compiled with /Od or /Odct in real mode. When compiled in protected
 mode, the compiler will issue a protection violation error.


 350. System Languages Do Not Generate 386-Code, 32-Bit Addressing

 Product Version(s): 3.x 4.00 4.01 4.10 | 4.10
 Operating System:   MS-DOS             | OS/2
 Flags: ENDUSER | S_Pascal h_masm S_C S_QuickC
 Last Modified: 18-AUG-1988    ArticleIdent: Q31663

    The system languages C, FORTRAN, MASM, and Pascal do not generate
 386-code or use 32-bit addressing. However, the Microsoft Macro
 Assembler will assemble 386 instructions, but it will not use 32-bit
 addressing. For more information on the Macro Assembler, please see
 the "Microsoft Macro Assembler Programmer's Guide" (Version 5.10).
    This limitation occurs because the operating systems on which our
 system languages operate, MS-DOS and OS/2, do not make use of the
 32-bit addressing available with the 80386 processor. These operating
 systems, and the system languages, will all execute on a 80386
 machine; however, they will behave as if it is a fast 80286 machine.
 The high-level system languages have the compile-time options /G0,
 /G1, and /G2. These options tell the compiler to generate code for the
 8086/88, 80186/188 and 80286, respectively.


 351. Returning a Floating-Point Value to FORTRAN from Assembly

 Product Version(s): 4.10
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 23-JUN-1988    ArticleIdent: Q31714

   The following FORTRAN and assembly code will demonstrate how to pass
 an integer value to an assembly routine from FORTRAN, perform some
 floating-point function, and then return the new floating-point value.
 (For more information on returning a floating-point value to a FORTRAN
 main from an assembly procedure, see Pages 78-79, Section 6.1.6, in
 the "Microsoft Mixed-Language Programming Guide.")

        INTERFACE TO REAL*4 FUNCTION M(I,J)
        INTEGER*4 I,J
        END

        INTEGER*4 I,J
 C*****Note that the function M is defined below*****
        REAL*4 L,M
        I =  1680649580
        J = 32
        L = M(I,J)
        PRINT *, L
        END

 ;***********Assembly Module**********
 .MODEL LARGE
 .CODE
         PUBLIC  M
 M       PROC FAR
         push    bp      ;Save old base pointer
         mov     bp,sp   ;Establish bp as the "framepointer"
         sub     sp,4
         finit
         les     bx,DWORD PTR [bp+8]     ;J
         fild    DWORD PTR es:[bx]       ;Push J on the coprocessor stack
         les     bx,DWORD PTR [bp+12]    ;I
         fild    DWORD PTR [bx]          ;Push I on the coprocessor stack
         fdiv    ST,ST(1)                ;Perform the division
         mov     bx,WORD PTR [bp+6]      ;Move the return value offset into bx
         fstp    DWORD PTR [bx]          ;Pop the coprocessor stack
         fwait
         finit
         mov     ax,bx              ;Move the return value offset into ax
         mov     dx,ds              ;Move the data segment value into dx
         mov     sp,bp              ;Recover old stack pointer(sp)
         pop     bp                 ;Get old bp
         ret     10                 ;Return 10 since 2 4-byte args were passed

 M       ENDP
         END



 352. EQUIVALENCEing Subroutine Argument in FORTRAN 4.10

 Product Version(s): 4.10 5.00
 Operating System:   OS/2
 Flags: ENDUSER | buglist4.10 fixlist5.00
 Last Modified:  7-NOV-1989    ArticleIdent: Q31831

 The following subroutine causes a protection violation while it is
 compiling with the default switches under OS/2 with FORTRAN Version
 4.10.

 The workaround is to perform the EQUIVALENCE outside of the
 subroutine, and then pass both arguments to the subroutine.

 Microsoft has confirmed this to be a problem with FORTRAN Version
 4.10. This problem was corrected in Version 5.00.

 The following is a code example:

         subroutine sub (line)

         equivalence (lyne,line)
         return
         end

 Using a subprogram argument in an EQUIVALENCE statement does not
 conform to the FORTRAN 77 Standard. This subroutine causes the
 following syntax error with the FORTRAN Versions 4.01 and 4.10
 compilers under DOS:

 eq.for
 eq.for(3) : error F2312: LINE : EQUIVALENCE : formal argument illegal


 353. Third-Party Libraries Available for Microsoft FORTRAN

 Product Version(s): 3.x 4.x
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified:  3-OCT-1990    ArticleIdent: Q31838

 Microsoft FORTRAN for MS-DOS provides a number of utilities and math
 libraries. In addition, there are a number of subroutines and
 libraries that can be obtained through third-party software vendors
 that could further speed your development.

 There are a range of graphic libraries available, such as the
 following:

 1. Plotting libraries (ATC, Microcompatibles, GSS), 3-D graphics
    (Microcompatibles)

 2. ANSI/ISO graphics (GSS, ATC)

 3. Image processing (Werner Frei)

 4. General graphics (Media Cybernetics)

 For data management, Softcraft provides Btrieve for ISAM support
 and Microrim provides a Microsoft FORTRAN program interface to its
 RBase product.

 Although FORTRAN math support is extensive, there are other more
 specialized math libraries available, such as the following:

 1. Modeling (Mitchell & Gauthier)

 2. FFT (MicroWay, Wiley)

 3. Vector

 4. Matrix

 5. Numerical analysis

 6. Signal and image processing libraries (Wiley, Quantitative
    Technology Corporation, Systolic Systems)

 7. Statistic (Wiley, IMSL, MAGUS, IMSL)

 8. Broad engineering/scientific math libraries (Wiley, NAG)

 General-purpose libraries are available through MEF that provide
 the following support in one package:

 1. Communications

 2. File management

 3. Graphics

 4. DOS

 5. Screen handling

 6. String handling

 Even very specialized libraries such as IEEE 488 Support (Tecmar)
 are available.

 Contact these third-party vendors for more information on their
 libraries for Microsoft FORTRAN or obtain a copy of the Language
 Support Directory by contacting Microsoft Sales and Service at (800)
 426-9400.


 354. Internal Compiler Error: p2symtab.c 1.85, Line 915

 Product Version(s): 4.10
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist4.10 fixlist5.00
 Last Modified:  6-NOV-1989    ArticleIdent: Q31846

 If the EQUIVALENCE statement follows the initializing TYPE statement,
 the correct F2311 error is generated. If the EQUIVALENCE statement
 precedes the TYPE statement, then P1 does not produce an error and P2
 fails with a p2symtab.c assertion error.

 The workaround is to declare the variables before you EQUIVALENCE
 them.

 Microsoft has confirmed this to be a problem in Version 4.10. This
 problem was corrected in Version 5.00.

 The following internal compiler error was produced by the code
 below:

 t71.for
 t71.for(4) : fatal error F1001: Internal Compiler Error
                 (compiler file '@(#)p2symtab.c:1.85', line 915)
                 Contact Microsoft Technical Support

 The following code demonstrates the problem:

        equivalence (fmt(1),prefix)
        character*4 prefix/'73h '/
        character*1 fmt(80)
        end

 If the EQUIVALENCE statement is placed after the two character-type
 lines, then the compiler will produce the correct error message, as
 follows:

 t71.for
 t71.for(3) : error F2311: PREFIX : EQUIVALENCE : preinitialization
 illegal


 355. Program Statement in Incorrect Order in Graphics Examples

 Product Version(s): 5.00
 Operating System:   MS-DOS
 Flags: ENDUSER | docerr
 Last Modified: 23-APR-1990    ArticleIdent: Q60843

 The PROGRAM statement in the code examples listed below is incorrect
 and should come AFTER the INCLUDE 'FGRAPH.FI' statement, but BEFORE
 the INCLUDE 'FGRAPH.FD' statement. The code examples are from the
 "Microsoft FORTRAN Advanced Topics" manual listed on the following
 pages:

 1. Function getcolor on Page 204

 2. Subroutine getcurrentposition, getcurrentposition_w on Page 205

 3. Subroutine getfillmask on Page 207

 4. Function getpixel, getpixel_w on Page 215

 5. Subroutine setfillmask on Page 256

 In the examples listed above, the (incorrect) heading for the source
 code is as follows:

        PROGRAM [program_name]

        INCLUDE 'FGRAPH.FI'
        INCLUDE 'FGRAPH.FD'

 The headings should instead be as follows:

        INCLUDE 'FGRAPH.FI'

        PROGRAM [program_name]

        INCLUDE 'FGRAPH.FD'

 The include file FGRAPH.FI includes interface statements for the
 graphics routines in the graphics library. Microsoft FORTRAN requires
 the interface statements to be located outside of a program block of
 code in a source file. In the first example above, the interface
 statements would be placed inside the main program code block, thus
 causing compile errors. The second example above solves the problem by
 placing the interface statements outside of the main program block of
 code.


 356. FORTRAN Academic 10-Packs

 Product Version(s): 5.00   | 5.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified: 24-APR-1990    ArticleIdent: Q60978

 Microsoft FORTRAN Academic 10-Packs is a new product for academic
 users.

 The FORTRAN Academic 10-Packs are designed for math, engineering, and
 scientific professors in schools and universities. Like Microsoft's
 other academic 10-packs, the FORTRAN 10-pack consists of 10 disk sets
 and one complete set of documentation, and is intended for use in
 labs. The suggested retail price, before discounts, is $1395. That
 equates to a per-workstation price, before discounts, of $139.50.

 The planned availability date is June, 1990.

 To order, or to obtain further information about the Microsoft FORTRAN
 10-Pack, call Microsoft Education Sales at (800) 227-4679.

 Some of the benefits to the Microsoft FORTRAN Version 5.00 10-Packs
 are the following:

 1. Certified ANSI 77 FORTRAN compiler

 2. Selected ANSI 8X extensions

 3. A complete product, including the FORTRAN compiler

 4. The CodeView debugger

 5. The Microsoft Editor

 6. The same professional-quality software as the retail FORTRAN 5.00
    product

 Additional manuals and conversion to 3.5-inch or 5.25-inch disk sets
 are available through Microsoft's Education Sales.


 357. FORTRAN and C Compatibility in Protected Mode

 Product Version(s): 4.10   | 4.10
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified: 21-JUL-1988    ArticleIdent: Q32044

    When FORTRAN libraries have been built with C compatibility, link
 the FORTRAN and C modules as follows:

    LINK objs,,,LLIBCEP.LIB LLIBFEP.LIB DOSCALLS.LIB /NOE /NOD;

    It is not necessary to use F4COMPAT.BAT for protected-mode
 programs. Any of the three math packages can be used as long as they
 are consistent between the languages. The C library must be the first
 library, the FORTRAN library and DOSCALLS.LIB must be linked
 explicitly, and the switches /NOE and /NOD must be used. The /NOE
 switch is used to prevent symbols from being defined more than once
 (error L2025). The /NOD switch turns off the default library search so
 that the order of these libraries can be given explicitly.
    For information on linking real-mode programs, please refer to the
 "Linking Mixed-Language Programs" section in the C Version 5.00
 README.DOC.


 358. Missing Files for Writing C Extensions

 Product Version(s): 4.10   | 4.10
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | appnote
 Last Modified:  7-NOV-1988    ArticleIdent: Q32046

 Page 68 of the "Microsoft Editor User's Guide," Section 8.1, states
 the following requirements for creating C extensions for the Microsoft
 Editor:

 "To create C extensions, you need to have the following files and
 software present in your current directory:

    Microsoft C Version 4.00 or later

    Microsoft Overlay Linker Version 3.60 or later or Microsoft

    Segmented-Executable Linker Version 5.01 or later

    EXTHDR.OBJ  (supplied with the editor)

    EXT.H       (supplied with the editor)

    SKEL.C      (a template that you can replace with your own code)"

 The three files EXTHDR.OBJ, EXT.H, and SKEL.C are not found on any of
 the Microsoft FORTRAN Version 4.10 Optimizing Compiler product disks.
 These three files are available from Microsoft System Languages
 Product Support by calling (206) 454-2030.


 359. Proper Use of SCWRQQ and LCWRQQ

 Product Version(s): 4.00 4.01 4.10 | 4.10
 Operating System:   MS-DOS         | 4.10
 Flags: ENDUSER | docerr
 Last Modified: 25-JUL-1988    ArticleIdent: Q32110

    On Pages 362-363 of the "Microsoft FORTRAN Optimizing Compiler
 User's Guide," there are references to the SSWRQQ and SCWRQQ functions
 and the LCWRQQ subroutine. These functions do not appear to work
 correctly (they are procedures to set and clear the floating-point
 exceptions).
    The documentation is incorrect; the last line of Page 362 refers to
 "SCWRQQ", which should be "SSWRQQ", as follows:

    INTEGER*2 FUNCTION SSWRQQ

    You cannot declare the subroutine "INTEGER*2 FUNCTION SCWRQQ", as
 stated in the documentation. The keyword function cannot be in the
 declaration. The FUNCTION statement is used for declaring user-defined
 functions and for the interface statement, as shown on Pages 218 and
 241 of the "Microsoft FORTRAN Optimizing Compiler Language Reference,"
 respectively.
    The following is an example:

       call rndzr
       stop
       end

       subroutine rndzr
 c   not "integer*2 function scwrqq" as the documentation states
       integer*2 scwrqq
       integer*2 cw

 c   get old control word
       cw = scwrqq()

 c   set new control word variable
       cw = 16#133f

 c   actually set new control word
       call lcwrqq(cw)
       return


 360. Minimal Support for Writing DLLs in FORTRAN 4.10

 Product Version(s): 4.10   | 4.10
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified: 21-JUL-1988    ArticleIdent: Q32144

    FORTRAN Version 4.10 should not be used to write Dynamic Link
 Libraries (DLL) for OS/2.

    Writing Dynamic Link Libraries in FORTRAN Version 4.10 is not
 feasible. Although it is possible to write a DLL using FORTRAN Version
 4.10, it may not be very useful: you cannot call any FORTRAN library
 routines. This includes the following restrictions:

    1. No floating point math
    2. Very little INTEGER*4 math
    3. No I/O
    4. No character operations except assignments
    5. No $DEBUG metacommand support for extended run-time error
       information

    A FORTRAN Version 4.10 DLL should be code only, no data, and no
 data or stack segment. The .DEF (module definition) file for the
 FORTRAN DLL should have the "NODATA" statement within it. This
 restriction requires that the process calling the DLL have MS-FORTRAN
 compatible initialization code for setting up a stack and data segment
 that the DLL could use, such as the initialization code produced from
 a main program module in Microsoft C, MS-FORTRAN, or MS-Pascal.
    Routines in a FORTRAN DLL should be able to receive arguments from
 the calling process by means of the formal parameters for the DLL
 routines. FORTRAN passes arguments by reference (by default);
 therefore, the DLL could modify the content of the arguments as long
 as the above restrictions are followed.


 361. Huge Addressing under OS/2

 Product Version(s): 4.10   | 4.10
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified: 20-OCT-1988    ArticleIdent: Q32206

 When a huge array is allocated space, OS/2 allocates segments from the
 Segment Selector Table in increments of n+0i, n+1i, n+2i, etc., where
 "n" is the starting selector and "i" is the incremental value. The
 value of "i" must be determined at load time for different versions of
 the OS/2 and for different configurations of the similar versions. The
 way that huge addressing is performed under OS/2 is identical to the
 way in which DOS accesses huge addresses. However, under DOS, "i" is
 always 4,096.

 Below is an example of how to obtain the value of "i" in a FORTRAN
 program. The value of "i" is 2 raised to the power returned by
 DosGetHugeShift. This information is discussed in detail in the
 Microsoft Press book "Inside OS/2" by Gordon Letwin, Section 9.2.2.

 The following example shows how to obtain the value of "i" in a
 FORTRAN program:

        INTERFACE TO INTEGER*2 FUNCTION DosGetHugeShift
       + [ALIAS: 'DOSGETHUGESHIFT'] (SHIFT)
        INTEGER*2 SHIFT
        END
        INTEGER*2 SHIFT,DosGetHugeShift
        INTEGER*2 I
        I = DosGetHugeShift(SHIFT)
        PRINT *,'DosGetHugeShift = ',SHIFT
        PRINT *,'i = ',(2**SHIFT)
        STOP
        END


 362. Protection Violation When Compiled with Defaults under OS/2

 Product Version(s): 4.10
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist4.10 fixlist5.00
 Last Modified: 16-JUN-1989    ArticleIdent: Q32227

 The program below generates a protection violation when compiled with
 the defaults under OS/2. When compiling under DOS, the program either
 hangs the compiler or generates code that does not function properly.
 The error occurs only when the statement labeled 6 is in the program.

 The workaround for this problem is to compile the program with the
 /Odclt option; this causes the compiler to enforce alias checking
 during optimization.

 Microsoft has confirmed this to be a problem in Version 4.10 of the
 FORTRAN compiler. This problem was corrected in Version 5.00.

 The program is as follows:

 $STORAGE:2
 $NOFLOATCALLS
       COMPLEX F
       DIMENSION NUMBER(7),F(8192)
       N=16
       NROOT=4
       NRTWO=NROOT+NROOT
       NRQRT=NROOT/4
 5     CALL FFTO(F,N)
       NUMBER(3)=NUMBER(3)+N
 6     IF (NUMBER(3).LE.4096) GO TO 5
       WRITE(*,'(5H   T=,i3)')KLOCK()-K
       WRITE(*,'(8F9.4)')(F(I),I=N-NRTWO+1,N,NRQRT)
       WRITE(*,'(8F9.4)')(F(I),I=1,NRTWO,NRQRT)
       STOP
       END


 363. FORTRAN: Setting /link Options with FL Environment Variable

 Product Version(s): 4.10   | 4.10
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | buglist4.10 docerr
 Last Modified: 16-JUN-1989    ArticleIdent: Q32245

 Page 12 of the "Microsoft FORTRAN Optimizing Compiler Version 4.1
 Update" states that /link options can be specified with the FL
 environment variable. However, setting any /link options with the FL
 environment variable will cause the compiler to cease compiling with
 the following command line error:

    Command line error D2003 : missing source file name

 This problem is caused by the compiler reading the /link option before
 it has read the source filename. The identical error will occur if the
 /link option is given at the FL command before the source file, as in
 the following example:

    FL /link /INFO source.for


 364. The FORTRAN Substitute for C-Style Pointers (DOS and OS/2)

 Product Version(s): 4.10   | 4.10
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified: 21-JUL-1988    ArticleIdent: Q32253

    This article applies to both MS-DOS and MS OS/2 FORTRAN.
    On many computer systems, advanced FORTRAN programmers have been
 able to get around the lack of C-style pointers by using the intrinsic
 function LOC to get the address of variables and then calculating the
 out-of-bounds index to an array variable that will access the value of
 another variable. When this is attempted in Microsoft FORTRAN, some
 problems occur that are not traditionally a problem for FORTRAN
 programmers.

    The idea is to access the value of a variable by indexing outside
 the bounds of an auxiliary array. This is the FORTRAN kludge that
 substitutes for C-style pointers, which FORTRAN does not have. The
 following program fragment illustrates the method for NON-HUGE
 addressing:

          INTEGER*2 BASE(1),VAL1,VAL2
          INTEGER*4 VAL1_PTR,VAL2_PTR
           ...
          VAL1_PTR=(LOC(VAL1)-LOC(BASE))/2+1
          VAL2_PTR=(LOC(VAL2)-LOC(BASE))/2+1
           ...
 C                         These should match.   These should match.
          WRITE(*,*) VAL1, BASE(VAL1_PTR), VAL2, BASE(VAL2_PTR)

    For this method to work, the array must be allocated at a lower
 address than the variables to be referenced, and the type of the array
 must be the same as that of the variable accessed. Also, because the
 "pointer" we create is really an element index rather than a byte
 pointer, the array and the variable accessed must be aligned so that
 the distance in bytes between the beginning of the auxiliary array and
 the beginning of the variable accessed is divisible by the size of the
 value in bytes.
    This is not a problem for INTEGER*2s, because they are
 automatically aligned, or for any 1-byte types. But for 4-byte
 integers, for reals, and for character types other than CHARACTER*1,
 steps must be taken to enforce alignment, e.g. by using equivalence or
 common statements.
    Another problem occurs when the difference between the byte
 addresses of the variable and the base array is greater than 65536
 bytes. This causes the following problems:

    1. The base array must be accessed using huge indexing.
    2. The LOC function returns a standard DOS far pointer, which is
       not a linear address.

    LOC returns a double-word value: the high word contains the segment
 number and the low word contains the byte offset within the segment.
 Under DOS, the segment selector offset is 12 bits. Therefore, to get a
 linear address you have to shift the high word to the right 12 bits
 and add it to the low word. Under OS/2, the segment selector offset is
 variable and a call to the OS/2 system call DosGetHugeShift is
 necessary. To get a linear address you have to shift the high word to
 the right by HI_SHIFT bits and add it to the low word.
    The following code fragment is an example of how to calculate the
 linear HUGE address of the variable ABC:

       INTERFACE TO INTEGER*2 FUNCTION DosGetHugeShift
      + [ALIAS: 'DOSGETHUGESHIFT'] (HI_SHIFT)
       INTEGER*2 HI_SHIFT
       END
 C     ...
       INTEGER HI_SHIFT,LOC_ABC*4
 C  For DOS, HI_SHIFT would always be set to 12
       INTEGER*2 HI_SHIFT,DosGetHugeShift
       INTEGER*2 I
 C     ...
       I = DosGetHugeShift(HI_SHIFT)
       IF (I.NE.0) WRITE (*,*) 'Error getting Huge Shift'
       LOC_ABC=ISHFT(IAND(LOC(ABC),#FFFF0000),-HI_SHIFT) +
      +              IAND(LOC(ABC),#0000FFFF)
 C     ...
       END


 365. M Editor Converts Spaces to Tabs, Columns 73-80 Not Ignored

 Product Version(s): 4.10   | 4.10
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified:  6-OCT-1988    ArticleIdent: Q32323

 The ANSI standard for FORTRAN specifies that columns 73-80 are to be
 ignored by the compiler. The M editor, using the default settings,
 takes every eight spaces and converts them into a tab character to
 save file space. This process causes problems for the compiler because
 it does not convert these tabs back into spaces.

 Therefore, even if you press the SPACEBAR to move to Columns 73-80,
 the compiler will read this as Column 9 because 72 spaces are
 converted to nine tabs, with eight spaces per tab. If you set ENTAB:0
 in your TOOLS.INI file, the M Editor will not convert spaces to tabs
 and the files will be suitable to FORTRAN.


 366. Error F2600: "Function Directly Recursive" Not Documented

 Product Version(s): 4.00 4.01 4.10 | 4.10
 Operating System:   MS-DOS         | OS/2
 Flags: ENDUSER | docerr
 Last Modified:  7-JUL-1988    ArticleIdent: Q32344

    The FORTRAN compile-time error F2600 is not documented in the
 manuals or README.DOC files. The text of the error is "Function
 Directly Recursive." Recursive functions are not allowed in Microsoft
 FORTRAN, as documented on Page 218, second paragraph, of the
 "Microsoft FORTRAN Optimizing Compiler Language Reference" for
 Versions 4.00, 4.01, 4.10.


 367. PC and XT Floating Point Exceptions for C and FORTRAN

 Product Version(s): 4.10
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist4.10 fixlist5.00 H_Fortran
 Last Modified: 30-MAR-1990    ArticleIdent: Q32385

 When equipped with coprocessors, certain 8086 machines (IBM, Compaq,
 and clones) have exhibited floating-point exceptions. These
 exceptions, identified by error messages M6111 "Stack underflow" and
 M6101 "Invalid" are never supposed to occur with code generated by
 Microsoft compilers, as discussed on Page 284 of the "Microsoft C 5.1
 Optimizing Compiler User's Guide" and Page 448 of the "Microsoft
 FORTRAN 4.1 Optimizing Compiler User's Guide."

 This problem apparently occurs because the 8087 requires the 8086 to
 issue an FWAIT instruction prior to a coprocessor instruction. Also, a
 potential cause is that the BIOS does not meet specifications.

 Microsoft has confirmed this to be a problem in Version 4.10 of the
 FORTRAN compiler. The FWAIT problem was corrected in Version 5.00.

 An application note called FPFIX corrects the FWAIT problem. This
 application note is available from Microsoft Product Support Services
 by calling (206) 454-2030. BIOS upgrades should be considered as well.

 This information also applies to Microsoft C 5.10.

 The following information describes some of the problems inherent to
 the generation of floating-point exceptions M6101, M6108, M6110, and
 M6111. The errors M6101 and M6111 are of particular concern because
 the others offer alternate explanations, such as "too complex an
 expression."

 In the course of processing floating-point numbers, the 8087
 coprocessor runs into processing exceptions, for which INTEL has
 provided a variety of solutions. One solution is to mask the exception
 from your software. For a precise definition of masked, see the INTEL
 iAPX86/88.

 The other solution is to unmask the exception so an interrupt is
 issued and a software interrupt handler is invoked to deal with the
 exception. Microsoft prefers this solution. The basic architecture of
 the exception handling situation is as follows:

         _______                _______                 _______
        |       |     INTX     |       |       IR      |       |
        | 8086/8| <----------- | 8259A |  <----------- | 8087  |<--
        |_______|       2      |_______|        1      |_______|  |
            |                                      --->|_______|  |
            |                                      |              |
            |                                      |              |
       INTY | 3       _______                      |              |
            |        |       |                     |              |
            |        | bios  |----------------------              |
            |        |_______|                                  4 |
            |       _______________________________________       |
            |      |                                       |      |
            -----> |       MS INTERRUPT HANDLER            |------
                   |_______________________________________|

 Upon experiencing an exception, the 8087 issues an interrupt request
 (IR), which in the case of the 86/88, is fielded by the 8259A, the
 Programmable Interrupt Controller. In the 286 configuration, there are
 two 8259As (see Page 417 of the "MS-DOS Encyclopedia"). The 8259A then
 issues a hardware interrupt (INTX), which is received by the CPU. The
 CPU then issues a software interrupt (INTY), which is fielded by our
 interrupt handler.

 The interrupt handler clears the status flags and restarts the
 process. It appears this problem occurs because of the FWAIT
 instruction's omission. Another potential cause of the problem is the
 the BIOS version.

 The BIOs reportedly generating this problem is as follows:

    phoenix 1.46

 To diagnose a Compaq AT, run the Norton SI utility. If the date is
 4/85 or earlier, the BIOS most likely is faulty.

 The following machines reportedly cause these problems:

    IBM PC upgraded to a hard-disk configuration

    IBM XT with 3.5-inch drive

    ITT XL

    Compaq portable

    Compaq AT (prior to 4/85)

    The following references were used to prepare this information:

 1. "INTEL iAPX86/88 Programmers Reference Manual," Pages 6-18

 2. "INTEL iAPX86/88 Users Manual Hardware Reference," Section 3

 3. "INTEL 80286 and 80287 Programmers Reference Overview of
    Numeric Processing"

 4. "Microsoft C 5.1 Optimizing Compiler User's Guide"

 5. "Microsoft FORTRAN 4.1 Optimizing Compiler User's Guide"


 368. Internal Compiler Error: srclist.c 1.58 Line 1367

 Product Version(s): 4.10   | 4.10
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | buglist4.10 fixlist5.00
 Last Modified:  8-NOV-1989    ArticleIdent: Q32118

 Using the $SUBTITLE metacommand with the NULL set as an argument, and
 compiling with the /Fs switch, will generate the following fatal error:

    fatal error F1001: Internal Compiler Error
    (compiler file '@(#)srclist.c:1.58', line 1367)
    Contact Microsoft Technical Support

 The following code generates the fatal error above when compiled with
 the /c and /Fs switches:

             $TITLE: 'Test Title'
             $SUBTITLE: ''
             END

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

 1. Do not use the $SUBTITLE command with the NULL set. If you do not
    use the $SUBTITLE metacommand, FORTRAN will assign the NULL set to
    the subtitle set by default; therefore, using this metacommand is
    unnecessary.

 2. Do not compile with the /Fs switch. This process will cause the
    $SUBTITLE metacommand to be ignored.

 Microsoft has confirmed this to be a problem in Version 4.10 of the
 FORTRAN compiler. This problem was corrected in Version 5.00.


 369. Using FORTRAN Version 4.10 SETUP to Build Libraries Only

 Product Version(s): 4.10   | 4.10
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified:  6-OCT-1988    ArticleIdent: Q32524

 To build FORTRAN Version 4.10 libraries using the SETUP.EXE
 program, it is necessary to have previously set up the entire FORTRAN
 package, either by using the F choice in SETUP's Main menu screen or
 by copying the necessary files from the distribution disks by hand.

 Specifically, the LIB.EXE needed by SETUP must already be in your
 path. In addition, before running SETUP for building additional
 libraries, it is necessary to set the PATH so that the correct version
 of the LIB utility can be found by SETUP. Without this step, the
 message "error trying to run library manager" appears, and you are
 then returned to the SETUP Main menu.

 The Main menu gives the following choice, among the three choices
 presented:

 "To build a new library, press L. Do not try to build a new library
 unless you have already set up Microsoft FORTRAN."

 This message does not explain the necessity of having previously set a
 path to the LIB.EXE utility.


 370. Passing a FORTRAN Common Block to C

 Product Version(s): 4.00 4.01 | 4.10
 Operating System:   MS-DOS    | OS/2
 Flags: ENDUSER | s_c
 Last Modified: 12-JUL-1988    ArticleIdent: Q32665

    The following example demonstrates how to pass COMMON variables
 from FORTRAN to C. Make sure the memory models are consistent because
 FORTRAN and C have different defaults.

 FORTRAN PROGRAM

       INTERFACE TO SUBROUTINE CFUNC[C,ALIAS:'_cfunc']
       END
       INTEGER*2 A
       REAL*4 B
       CHARACTER*12 C
       COMMON /ABC[C,ALIAS:'_PTR']/ A, B, C

       A = 1
       B = 2.5
       C = 'HELLO WORLD' C
       CALL CFUNC()
       END

 C ROUTINE

 #include <stdio.h>

 void cfunc(void);      /* Function prototype                    */

 extern struct common_block
        {               /* structure that looks like the FORTRAN */
        int a;          /* common block                          */
        float b;
        char c[12];
        } PTR;

 void cfunc()
 {
 printf( "Element a = %d\n", PTR.a );
 printf( "Element b = %f\n", PTR.b );
 printf( "Element c = %s\n", PTR.c );
 }

 OUTPUT

 Element a = 1
 Element b = 2.500000
 Element c = HELLO WORLD


 371. Page Update-19 Refers to "Programmer's Guide"

 Product Version(s): 4.10   | 4.10
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | docerr
 Last Modified: 21-JUL-1988    ArticleIdent: Q32745

    Page Update-19 of the "Microsoft FORTRAN 4.10 Optimizing Compiler"
 manual, in the section marked "Update (FORTRAN 4.1)", refers to a
 manual titled "Microsoft Operating System/2 Programmer's Guide." This
 manual is not part of the FORTRAN Version 4.10 package.
    Manuals titled "Programmer's Reference" and "Programmer's Learning
 Guide" are provided with the Microsoft Operating System/2 Programmer's
 Toolkit.



 372. Redirected Input Incorrect after Error

 Product Version(s): 4.10   | 4.10
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified: 25-JUL-1988    ArticleIdent: Q33103

    The following program will work correctly when taking input from
 the console. However, when the input is redirected to take input from
 a file, it incorrectly rewinds to the beginning of the file if an
 error occurs.
    To work around this problem, open the input file and read from that
 unit, rather than reading from a redirected Standard Out.

    The error occurs when redirecting input (TEST < TEST.INP) from a
 file to the TEST.EXE program.
    The following is a sample code:

   character*40 line
       real  z
 10    continue
       read (*,*, err=30) z
       write(*,*) 'z = ', z
       goto 10

 30    read(*,'(a)') line
       write(*,*) line

       stop
       end

    The TEST.INP input file for the TEST.EXE program is as follows:

 1.0 this is first
 2.0
 3.0
 s
 5.0 this should print
 6.0



 373. /4Yb ($DEBUG) Not Checking for Integer Overflow in FORTRAN 4.1

 Product Version(s): 4.10 5.00  | 4.10 5.00
 Operating System:   MS-DOS     | OS/2
 Flags: ENDUSER | buglist4.10 fixlist5.00
 Last Modified:  7-NOV-1989    ArticleIdent: Q33107

 When compiled with the /4Yb option (or $DEBUG), the program below will
 not check for integer overflow, as stated in the manual.

 Microsoft has confirmed this to be a problem in Version 4.10. This
 problem was corrected in Version 5.00.

 To work around this problem, use a temporary variable instead of "k";
 replace "k = j * k" with "l = j * k". This process enforces the
 overflow checking.

 The following is a sample program:

 $DEBUG
       integer*2 i,j,k
       k = 1
       j = 2
 10    k = j * k
       write (*,*) k
       goto 10
       stop
       end


 374. Incorrect Code Generation in FORTRAN 4.10

 Product Version(s): 4.10 5.00 | 4.10 5.00
 Operating System:   MS-DOS    | OS/2
 Flags: ENDUSER | buglist4.10 fixlist5.00
 Last Modified:  7-NOV-1989    ArticleIdent: Q33109

 The FORTRAN Version 4.10 compiler seems to be generating some
 incorrect code in the following particular loop:

       INTEGER*2 A(3)
 10    READ(*,100,ERR=200) A(1)
 100   FORMAT(3I2)
       STOP
 200   GOTO 10
       END

 The program executes properly when an integer is entered; however,
 if a character or a number of characters (garbage) is entered, the
 error routine is called and the program goes back to the READ
 statement but falls. This problem causes an infinite loop at that
 point, jumping from 10 to 200 and back again, hanging the machine.

 By inserting a PRINT statement before the READ statement outside of
 the loop, the program will execute correctly. For example, place the
 following code line just before the READ statement:

       PRINT *,"HI THERE"

 Microsoft has confirmed this to be a problem in Version 4.10.
 This problem was corrected in Version 5.00.


 375. How to Combine Segments in DGROUP Part 2

 Product Version(s): 4.10   | 4.10
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | docerr S_QUICKC S_C S_PASCAL h_masm B_BBASIC B_QUICKBAS
 Last Modified: 30-SEP-1988    ArticleIdent: Q33114

 On Page 93 of the "Microsoft Mixed-Language Programming Guide" (and
 Page 307 of the "Microsoft QuickC Programmer's Guide" for Versions
 1.00 and 1.01 and Page 334 of the "Microsoft QuickBASIC 4.0 Learning
 and Using Microsoft QuickBASIC" manual), in the section describing how
 to combine segments in DGROUP part 2, the declaration is incorrect.

 The text incorrectly states the following:

 GROUP    DGROUP  _DATA _BSS

 The declaration should be as follows:

 DGROUP   GROUP   CONST, _BSS, _DATA

 Without this correction, assembling under Macro Assembler Versions
 5.00 or 5.10 will generate the "A2105: Expected: instruction,
 directive, or label" error. Under Macro Assembler Version 4.00, the
 assembly code generates the "error 10: Syntax error."


 376. Loop Optimization Problem in FORTRAN 4.10

 Product Version(s): 4.10 5.00  | 4.10 5.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | buglist4.10 fixlist5.00
 Last Modified:  7-NOV-1989    ArticleIdent: Q33118

 K does not get set to two with loop optimization on.

 To work around this problem, compile with /Odct.

 Microsoft has confirmed this to be a problem in Version 4.10 of the
 FORTRAN compiler. This problem was corrected in Version 5.00.

 The following is a sample program:

 $STORAGE:2
       PROGRAM F77BUG
       DIMENSION  II(7),IJ(7),IP(7),NJ(3),NE(3)
       DATA II/0,1,2,2,3,4,5/,IJ/1,2,3,4,5,5,6/,IP/3,3,3,15,3,3,28/
       DATA NJ/3*1/,NE/1,0,0/
       IU37 = 37
       OPEN(IU37,FILE='XXX.LIS',STATUS='UNKNOWN')
       ME = 1
       NA = 7
 CC     ORIGINAL PROGRAM CODE
       ISQ = 0
   400 continue
       MP = 32001
       K  = 1
       J  = NE(K)
       DO 440 I = K,ME
   440 continue
       NE(I) = NE(I+1)
       ME = ME - 1
       ISQ = ISQ + 1
       IP(J) = ISQ
       L = IJ(J)
       NJ(L) = NJ(L) - 1
       WRITE (IU37,441) K,ME,J,ISQ,L,NJ(L)
   441 FORMAT(' AFTER 440 ',6I6)
       IF(NJ(L))450,450,400
   450 continue
       I = 0
       J = NA + 1
   500 continue
       K = (I + J) / 2
       WRITE (IU37,501) I,J,K,L,II(K),NA
   501 FORMAT( ' 500 I,J,K,L II(K),NA',6I6)
       IF(J - I  - 1)400,400,460
   460 WRITE (IU37,*) ' 460   L K II(K) ',L,K,II(K)
       IF(L - II(K))470,490,480
   470 continue
       J = K
       GO TO 500
   480 continue
       I = K
       GO TO 500
   490 WRITE (IU37,*) ' 490 NOTE!!!! K VALUE IS 1 . K L ',  K ,L
       WRITE (IU37,*) ' IN LINE ABOVE K = 2      !! '
       WRITE (IU37,*) ' F77 MODIFIED K FROM 2 TO 1 !! '
       IF(K - 1)510,510,520
   520 IF(L - II(K-1))510,530,510
   530 continue
       K = K - 1
       GO TO 490
 CC REPLACED TO AVOID LOOP
 C 510 IF(L - II(K))400,540,400
   540 IF(K - NA)550,550,400
   550 continue
 9      ME = ME + 1
       NE(ME) = K
       K = K + 1
       WRITE (IU37,551) K,L,II(K),ME
   551 FORMAT( ' 550 K,L,II(K),ME',5I6)
       GO TO 510
   510 CONTINUE
  1100 END


 377. FORTRAN: F2124: Code Generation Error

 Product Version(s): 4.01 4.10 | 4.10
 Operating System:   MS-DOS    | OS/2
 Flags: ENDUSER | buglist4.01 buglist4.10 fixlist5.00
 Last Modified: 16-JUN-1989    ArticleIdent: Q33267

 The following program will cause a "code generation error" when
 compiled with /Od or /4Yb:

       real k3
       y = 2 * k3 + 2 * k6
       return
       end

 The following error is generated:

    flew.for(2) : error F2124: Code Generation Error
                 Contact Microsoft Technical Support

 Microsoft has confirmed this to be a problem in Versions 4.01 and
 4.10. This problem was corrected in Version 5.00.

 To work around this problem, break up the expression into separate
 expressions, one for the real variable k3 and one for the integer
 variable k6, and then combine the two expressions. The integer
 variable k6 could also be converted to a REAL, as follows:

    y = 2 * k3 + 2 * REAL (k6)


 378. FORTRAN Version 4.10 and C Compatibilty

 Product Version(s): 4.10   | 4.10
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified: 25-JUL-1988    ArticleIdent: Q33297

    When setting up FORTRAN Version 4.10, and you are asked whether to
 include C compatibility, consider that this option only will work
 correctly with C Version 5.00 or later.
    If you use C Version 4.00 and a FORTRAN library built with C
 compatibility, you will receive the "L2029 : Unresolved External
 __wrt2err" error.
    To work around this problem, build the FORTRAN libraries without C
 compatibility and use the /NOE switch at link time.



 379. Accessing Command-Line Arguments

 Product Version(s): 4.00 4.01 4.10 | 4.10
 Operating System:   MS-DOS         | 4.10
 Flags: ENDUSER | appnote
 Last Modified:  7-NOV-1988    ArticleIdent: Q33307

 An application note called "Version 4.x Accessing Command Line," which
 explains how to access the command line arguments under FORTRAN
 Versions 4.00, 4.01, and 4.10, is available from Microsoft Product
 Support Services by calling (206) 454-2030.

 The application note contains two files that must be compiled and
 linked with the your main program. Also included is an example
 program, which when compiled and linked with the other two files will
 demonstrate how a FORTRAN program can access the command line
 arguments.

 The following is a list of the files that make up the application note
 and a short description:

    CMDLIN.FOR   This routine returns the current command line
                 and its length.

    DREF.FOR     This routine is called from subroutine
                 CMDLIN and serves to "de-reference" the
                 arguments "CMDIN" and "NIN," which are sent
                 to this routine as addresses passed by value
                 (courtesy of the INTERFACE statement in subroutine
                 CMDLIN).

    TSTCMD.FOR   This routine tests subroutine CMDLIN, which
                 returns the current command line and its
                 length.

 The three provided routines may be compiled by the following FL
 command:

     FL TSTCMD.FOR DREF.FOR CMDLIN.FOR


 380. FORTRAN Gives "Error F2115: Syntax Error"

 Product Version(s): 4.01 4.10 | 4.10
 Operating System:   MS-DOS    | OS/2
 Flags: ENDUSER | buglist4.01 buglist4.10 fixlist5.00
 Last Modified: 16-JUN-1989    ArticleIdent: Q33308

 Page 296 of the "Microsoft FORTRAN 4.1 Optimizing Compiler Language
 Reference Mixed-Language Programming Guide" (Section 6.2.5) states
 that the $FREEFORM metacommand (or the /4Yf switch) is a specifier
 that tells the compiler that the source file is in the free-form
 format.

 In free-form FORTRAN programs, statement line numbers may start on a
 column other than column 1. Versions 4.01 and 4.10 of the compiler
 both generate "error F2115: syntax error."

 Microsoft has confirmed this to be a problem in Versions 4.01 and
 4.10 of the Microsoft FORTRAN Optimizing Compiler. This problem was
 corrected in Version 5.00.

 To work around this problem, make sure all the labels start in the
 first column.

 The following sample code demonstrates the problem:

 $FREEFORM
 write (*,1)
 1           format( 1x, 'Label on column 1 is OK' )

  write (*,2)
  2          format( 1x, 'Gives error F2115: syntax error' )

 end


 381. FORTRAN: Common Subexpression Optimizer Fails in 4.10, 5.00

 Product Version(s): 4.10 5.00   | 4.10 5.00
 Operating System:   MS-DOS      | OS/2
 Flags: ENDUSER | buglist4.10 buglist5.00
 Last Modified:  6-NOV-1989    ArticleIdent: Q33309

 The code below demonstrates a bug in the common subexpression
 optimizations of Versions 4.10 and 5.00 of the FORTRAN compiler. If
 you compile this code with the full optimization default, the
 resulting output for the variable C is incorrect.

 Microsoft has confirmed this to be a problem in Versions 4.10 and
 5.00. We are researching this problem and will post new information as
 it becomes available.

 To work around this problem, compile the code with /Odlt optimization,
 or change the line C=X(I) to an equivalent statement, as follows:

    TEMP = I
    C = X(TEMP).

 This problem occurs because the optimizer generates code for the line
 C=X(I) that reevaluates the division of A and B rather than doing a
 simple assignment. This process assigns C to 1.0 regardless of the
 input values of A, B, or X(I).

 The following is a sample code:

               real x(10)
               read(*,*) i,a,b

               x(i)=a/b
               a=b
               c=x(i)

               write(*,*) c
               end


 382. Interfacing between Assembly Language and FORTRAN

 Product Version(s): 4.00 4.10 | 4.10
 Operating System:   MS-DOS    | OS/2
 Flags: ENDUSER | h_masm
 Last Modified: 18-AUG-1988    ArticleIdent: Q33351

    When assembler routines are called from FORTRAN, the assembler
 routine should obey certain rules.
    The first rule applies if you compile your FORTRAN routine with /Os
 or /Op. Optimizing your program will cause FORTRAN to use the SI and
 DI registers extensively. An assembly routine that changes SI and DI
 is responsible for saving and restoring the registers. The Microsoft
 FORTRAN Compiler also assumes that the direction flag is always
 cleared.
    In assembler, the direction flag can be cleared by using the CLD
 instruction. As a general rule, the segment registers, DS, SS, and ES
 should also be preserved.
    For more information on this topic, see the "Microsoft
 FORTRAN Optimizing Compiler User's Guide", Chapter 11 "Interfaces with
 Assembly Language and C," section 11.2.9 "Register Considerations."



 383. Using C for Carriage Control for FORTRAN OUTTEXT

 Product Version(s): 5.00   | 5.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified: 26-JUL-1990    ArticleIdent: Q63966

 The OUTTEXT graphics function included with Microsoft FORTRAN version
 5.00 does not provide any carriage control features. Some carriage
 control can be added by calling OUTTEXT from a C subroutine and
 passing a C string to the function. The C string can include some of
 the escape sequences described on Page 16 of the "Microsoft FORTRAN
 Reference" manual for version 5.00. The '\n' sequence, for example,
 will generate a new line.

 The following code shows an example of passing a string to a C
 subroutine and using the OUTTEXT function:

 FORTRAN CODE

       INTERFACE TO SUBROUTINE outc [C] (cstring)
       CHARACTER*(*) cstring [REFERENCE]
       END

       INCLUDE 'fgraph.fi'

       PROGRAM out

       INCLUDE 'fgraph.fd'

       INTEGER*2 dummy
       CHARACTER*10 cstring

       dummy = setvideomode($MAXRESMODE)

       cstring = 'LINE 1\n' C               ! C string with
       CALL outc(cstring)                   ! escape sequence

       cstring = 'LINE 2' C
       CALL outc(cstring)

       READ (*,*)
       dummy = setvideomode($DEFAULTMODE)
       END

 C CODE:

 void outc(char * string)
 {
     _outtext(string);
 }

 The output produced by this code is as follows:

 LINE 1
 LINE 2

 If OUTTEXT is called from FORTRAN, the C string escape sequence '\n'
 is not recognized, and a new line is not generated. There is a
 difference between the way in which OUTTEXT is used and interpreted
 between the two languages.

 Not all the C string escape sequences listed in the FORTRAN
 manual are supported in graphics mode.

 The sequences that are supported are as follows:

    \n, \r, \\, \'', \", \xhh, and \ooo

 The sequences that are not supported are as follows:

    \a, \b, \f, \t, and \v

 This program was tested using versions 5.10 and 6.00 of C under DOS
 and OS/2. To compile and link this program use the following:

         FL /c out.for
         CL /c  /AL outc.c

         (linking under DOS)

         LINK out outc,,,/nod /noe (flib) (clib) graphics;

         where:
                 (flib) is the FORTRAN library,
                 (clib) is the C library, and
                 'graphics' is the FORTRAN 5.00 Graphics Library.

 It is NOT necessary to link with the C Graphics Library. The OUTTEXT
 function is resolved correctly with the FORTRAN library.

         (linking under OS/2)

         LINK out outc,,,/nod /noe (flib) (clib) doscalls
                 grtextp;

         where:
                 'doscalls'is the import library for OS/2 API
                         calls, and
                 'grtextp' is the FORTRAN 5.00 OS/2 Graphics
                         Library.

 When linking with the C 6.00 libraries, it is possible to get the
 following errors:

    ...L2025: STKHQQ : symbol defined more than once
    ...L2025: __aaltstkovr : symbol defined more than once
    ...L2025: __chkstk : symbol defined more than once

 Under DOS this does not affect the program. Under OS/2, however,
 running the program causes a system error. This can be corrected by
 removing the CHKSTK module from the FORTRAN library. For more
 information on this process, query on the words following words:

    L2025 and CHKSTK.ASM


 384. Loop Optimization Problem

 Product Version(s): 4.00 4.01 4.10 | 4.10
 Operating System:   MS-DOS         | OS/2
 Flags: ENDUSER | buglist4.10 fixlist5.00
 Last Modified:  6-NOV-1989    ArticleIdent: Q33480

 The following program incorrectly executes the loop only once when
 compiled with loop optimization:

       PROGRAM TEST
          INTEGER J(16:30)
          DO 20 I=16,30
 20    J(I) = 2**(62-2*I)
          WRITE (*,'(I11)') J
          END

 Microsoft has confirmed this to be a problem in Version 4.10 of the
 FORTRAN compiler. This problem was corrected in Version 5.00.

 To work around this problem, either disable the loop optimization or
 make the following modification to the code:

 20       J(I) = 2**(62-(2*I))

 By forcing the desired order of precedence with parentheses, the loop
 is correctly executed.


 385. Internal Compiler Error ctypes.c 1.89 Line 1601

 Product Version(s): 4.10   | 4.10
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | buglist4.10 fixlist5.00
 Last Modified:  6-NOV-1989    ArticleIdent: Q33484

 When compiled with /Od, the code below generates the following error:

           fatal error F1001: Internal Compiler Error
                 (compiler file '@(#)ctypes.c:1.89', line 1601)
                 Contact Microsoft Technical Support

 Microsoft has confirmed this to be a problem in Version 4.10. This
 problem was corrected in Version 5.00. The workaround is given below.

 The following is the code:

       subroutine feedch()

       double precision nr, sri, ssg, vgc, zabp, dent1,
      +                 dent2, dent3

       IF (NRSW.EQ.1)
      1 NR=117.4D0-363.D0*SRI+263.7D0*SSG+288.6D0*VGC-69.2D0
      2    *ZABP*1.D-3+40.6D0*ZABP*ZABP*1.D-6

       end

 This error can be avoided by compiling with any optimization other
 than /Od, or by changing the code to the following:

       IF (NRSW.EQ.1)
      1  THEN
         dent1 = 117.4d0 - (363.d0 * sri)
         dent2 = (263.7d0 * ssg) + (288.6d0 * vgc)
         dent3 = (69.2d0 * zabp * 1.d-3) + (40.6d0 * zabp *
      1         zabp * 1.d-6)
         nr = dent1 + dent2 - dent3
         endif


 386. Linking FORTRAN Version 4.10 with Version 3.3x Modules

 Product Version(s): 3.20 3.3X 4.00 4.01 4.10
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 13-JAN-1989    ArticleIdent: Q35397

 I am linking some FORTRAN Version 4.10 object modules with object
 modules that have been compiled with FORTRAN Version 3.20 or 3.3x. I
 have built the Version 4.10 libraries with Version 3.30 compatibility
 and I am linking with compatibility library, FORTRAN.LIB. I always
 receive the errors below.

 The solution to this problem is to use the /NOD switch and to
 link with the FORTRAN.LIB first.

 The following errors demonstrate the problem:

 Microsoft (R) Segmented-Executable Linker  Version 5.01.20
 Copyright (C) Microsoft Corp 1984-1988.  All rights reserved.

 d:\lib\FORTRAN.LIB(MANV) : error L2025: __fltused : symbol defined more than
 once
  pos: 4F38 Record type: 7D04

 LINK : error L2029: Unresolved externals:

 __cfltcvt_tab in file(s):
  d:\lib\LLIBFORE.LIB(..\fltused.ASM)
 __cfltcvt in file(s):
  d:\lib\LLIBFORE.LIB(..\fltused.ASM)

 There were three errors detected.

 This problem occurs because the linker first tries to resolve all the
 externals in the .OBJs. It will resolve as many externals as possible
 from the first library and then try to resolve the functions that the
 library has. It will then go to the next library and do the same
 thing. It will not go back to the previous libraries, so the order of
 the libraries is critical.

 The following is an example of a proper link line:

 LINK test1.obj test2.obj,,,fortran.lib llibfore.lib /NOD;

 For more information on Versions 3.20 or 3.30 compatibility, see
 section 2.4.6.6 in the "Microsoft FORTRAN Optimizing compiler User's
 Guide", Page 33.


 387. Integer Overflow Is Not Flagged for Some Values

 Product Version(s): 4.10   | 4.10
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | buglist4.10 fixlist5.00
 Last Modified:  6-NOV-1989    ArticleIdent: Q33719

 Version 4.10 of the FORTRAN Compiler does not flag the range
 2,147,614,720 to 4,295,229,439 as an integer overflow for an INTEGER*4
 variable. The maximum value for an INTEGER*4 is 2,147,483,647.

 The sample code below demonstrates this problem. If you enter a number
 within the above inclusive range, this program returns an erroneous
 value. If you enter a number that is larger than the largest INTEGER*4
 value, but not within this range, an integer overflow and subsequent
 read error occurs.

 Microsoft has confirmed this to be a problem in Version 4.10. This
 problem was corrected in version 5.00.

 The following is the sample code:

        INTEGER*4 TEMP
        TEMP = 0

        write(*,*) 'enter an integer value'
        READ(*,*,err=20) TEMP
        write(*,*) 'result:'
        write(*,*) temp

 20     write(*,*) 'Error in read statement'
 30     END


 388. FORTRAN Compiler Causes a Null-Pointer Assignment

 Product Version(s): 4.10 5.00 | 4.10 5.00
 Operating System:   MS-DOS    | OS/2
 Flags: ENDUSER | buglist4.10 fixlist5.00
 Last Modified:  7-NOV-1989    ArticleIdent: Q33727

 The sample code below causes the "F1900: Maximum memory allocation
 size exceeded" error, then generates a null-pointer assignment error
 R6001 when compiled under DOS.

 Under OS/2, the result is a general-protection failure. However, in
 the DOS compatibility box, the result is simply the error F1900 with
 no subsequent null-pointer assignment.

 Microsoft has confirmed this to be a problem in Version 4.10 of the
 FORTRAN compiler. This problem was corrected in Version 5.00.

 The following is the sample code:

 $INCLUDE:'INFTST1.INF'
         SUBROUTINE INFTST1(A,N)

         INTEGER*2       N
         INTEGER*2       A(N)
         A(1) = 1
         END

 c      (include file: inftst1.inf)
         INTERFACE TO SUBROUTINE INFTST1(A,N)
         INTEGER*2       N
         INTEGER*2       A(N)
         END


 389. Internal Compiler Error exphelp.c:1.55, Line 1308

 Product Version(s): 4.00
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist4.00 fixlist4.01
 Last Modified:  5-AUG-1988    ArticleIdent: Q33728

    The sample code below generates the following error:

    test.for(9) : fatal error F1001: Internal Compiler Error
                 (compiler file '@(#)exphelp.c:1.55', line 1308)
                 Contact Microsoft Technical Support

    Microsoft has confirmed this to be a problem in Version 4.00. This
 problem was corrected in Version 4.01.
    This error can be avoided by compiling with /Odclt.

    The following sample code demonstrates the problem:

       program grid
       real gridd(4,4), nugrid(4), x(4)
       data x/-1000.0, -5000.0, 0.0, -7500./
       data ((gridd(i,J), i=1,4), J=1,4) /-3.0, 1.0, 0.0,0.0,
      +5.0,-24.0,5.0,4.0,0.0,1.0,-5.0,0.0,0.0,4.0,0.0,-34.0/
       print *, 'grid(4,4)  :'
       print *, ((gridd(I,j), i=1,4), j=1,4)
       do 20 k=1,4
         do 10  i=1,4
             do 10 j=1,4
 c            temp=gridd(i,j)*x(j)
             nugrid(k)=nugrid(k)+temp
 10    continue
 20    continue
       print *, 'nugrid = ',(nugrid(n), n=1,4)
       end


 390. Formatted READ Reads Past CTRL+Z in Disk File

 Product Version(s): 4.10   | 4.10
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified: 13-JAN-1989    ArticleIdent: Q34060

 Question:

 I updated to FORTRAN Version 4.10 from FORTRAN Version 3.31. My
 program reads a formatted file that contains a CTRL+Z character to
 mark the end of the file. Because the file was created with an old
 program that uses File Control Block (FCB) I/O, the file is padded to
 a 128-byte boundary with random characters after the CTRL+Z.

 My program worked correctly under Version 3.31, stopping when it hit
 the CTRL+Z. However, it reads right past the CTRL+Z under Version
 4.10, not stopping until it reads all of the characters in the file.
 What is wrong?

 Response:

 The FORTRAN I/O library has been rewritten to increase the speed of
 I/O. One of the side effects of the rewrite is that the CTRL+Z
 character will not be recognized as marking the end-of-file in files
 that are in the format described above.

 To work around this problem, do one the following:

 1. Use binary mode and read character-by-character, checking for the
    CTRL+Z in each character. This process is likely to be quite slow.

 2. Read into CHARACTER*x variables in formatted mode and check each
    string read for CTRL+Z using the INDEX function. This process
    should be faster.

 3. Modify the input file so that its actual length is the same as
    its logical length or so all of the characters after the CTRL+Z
    are either CTRL+Zs or nulls (ASCII code = 0). This process is
    best if you do not mind passing the input file through a filter.


 391. File I/O Return Codes Using IOSTAT

 Product Version(s): 3.x 4.00 4.01 4.10 | 4.10
 Operating System:   MS-DOS             | OS/2
 Flags: ENDUSER |
 Last Modified: 18-AUG-1988    ArticleIdent: Q33730

 Question:
    I opened a file and received a return code with IOSTAT. Where can
 I look to find out what this code means?

 Response:
    If the number you received is zero, there was no error; however,
 if you received a positive number back, there was an error and the number
 corresponds to a run-time error message.
    The run-time error messages are documented starting on Page 434 of
 the "Microsoft FORTRAN 4.1 Optimizing Compiler Users Guide."


 392. Passing a FORTRAN String to a C Function

 Product Version(s): 4.10   | 4.10
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | s_c
 Last Modified: 16-AUG-1988    ArticleIdent: Q33763

    The following example illustrates how to pass a FORTRAN string to a
 C function and return a capitalized version of the string. The string
 passed remains unchanged. For additional information, see the
 "Microsoft Mixed-Language Programming Guide", sections 4.1, 4.2, and
 4.4.

    When passing a string from FORTRAN to C, the FORTRAN interface
 statement must have the following form:

    INTERFACE TO return_type FUNCTION func_name [C] ( ARG )
    return_type ARG [REFERENCE]

    In the above declaration "return type" can be any type, such
 as character*30. Note that all data types are references (addresses)
 in FORTRAN.
    The [C] attribute tells FORTRAN to treat the function as a C
 function. This attribute accomplishes the following:

    1. Pushes parameters from left to right
    2. Appends a leading underscore to the function name
    3. Prepares the calling program to take care of the stack unlike
       FORTRAN and Pascal, in which the called sub-program takes care
       of the stack.
    4. The C attribute is also used to tell FORTRAN that a string
       literal is to be treated as a C string; i.e., to place a NULL
       terminator after the literal in the CONST segment of DGROUP.

    The [REFERENCE] attribute tells FORTRAN to pass the address of ARG
 instead of its value. Note that the value of ARG is an address; as a
 result, its address is passed. There are two levels of indirection
 similar to a pointer in C (e.g. char **p).
    The following is an example of mixed language calling C from
 FORTRAN:

       interface to character*30 function UpCase [C] ( str )
       character*30 str [REFERENCE]
       end

       character*30 string
       character*30 buffer
       character*30 UpCase

       string = 'hello, world!'  C

 C     The C following 'hello, world!' NULL terminates the literal.

       buffer = UpCase( string )

       write(6, 10) string
       write(6, 11) buffer

   10  format( 1x, 'string = ', A13 )
   11  format( 1x, 'buffer = ', A13 )

       end

 =====================================================================
 PRINTOUT:

 string = hello, world!
 buffer = HELLO, WORLD!

 =====================================================================

 C:

 #include <malloc.h>

 char *
 UpCase( const char *string )
 {
      int   i=0;
      char  *str; /* Create buffer so you do not change string value */

      while ( string[i++] != 0 );   /* Get string length */
      str = malloc( --i );          /* Give buffer some space */

      i = 0;
      while ( string[i] != 0 ) /* Change to uppercase, copy into str */
      {
           if ( string[i] >= 'a' && string[i] <= 'z' )
                str[i] = string[i] - 32;
           else
                str[i] = string[i];
           i++;
      }

      return( str );
 }


 393. Using the Debug Option with /Zi Causes Problems

 Product Version(s): 4.00 4.01 4.10 | 4.10
 Operating System:   MS-DOS         | 4.10
 Flags: ENDUSER | s_pascal SR# G880727-1846
 Last Modified:  5-AUG-1988    ArticleIdent: Q33832

    The two compiler switches /Zi and /4Yb for FORTRAN, or /Pd for
 Pascal are mutually exclusive. The line information that each of these
 store, conflicts with each other. If both are used and the code is
 brought up under CodeView, the source comes up in assembly mode with
 the statement, No Symbolic Information.  There is no reason to turn on
 the debugging switch if you intend to do your debugging in CodeView.

    The use of the Pascal /Pd switch is identical to the PAS1 option
 /D, which turns on all debugging. The FORTRAN /4Yb switch also turns
 on all debugging. These are equivalent to the $DEBUG metacommand.


 394. FORTRAN: Error F2409 Erroneously Generated

 Product Version(s): 4.10   | 4.10
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | buglist4.10 fixlist5.00
 Last Modified: 16-JUN-1989    ArticleIdent: Q33898

 The sample program below causes the error F2409: "nonstatic address
 illegal in initialization." If the $NOTRUNCATE command is given at the
 top of the program, it compiles cleanly. If INDEXER in shortened to
 INDEXE, i.e., six characters, the program compiles without error.
 Microsoft FORTRAN only recognizes the first six characters of the
 variable name unless the $NOTRUNCATE command is given.

 Microsoft has confirmed this to be a problem in Version 4.10. This
 problem was corrected in Version 5.00.

 The following sample program demonstrates the problem:

        DIMENSION A(5,5)
        DATA (( A(INDEXER, J), INDEXER=1,5), J=1,5) /25*1.0/
        END

 bug.for(2) : error F2409: A : nonstatic address illegal in initialization


 395. How to Avoid Compiler Error F6700: "Heap Space Limit Exceeded"

 Product Version(s): 4.00 4.01 4.10 | 4.10
 Operating System:   MS-DOS         | OS/2
 Flags: ENDUSER |
 Last Modified:  7-SEP-1988    ArticleIdent: Q33995

 Problem:

 I have received the F6700: "heap space limit exceeded" run-time error.
 The error documentation implies that I may have too many files opened
 at once; however, this is not the case. I have files=20 in my
 CONFIG.SYS and I only have opened five files myself.

 Response:

 This problem may occur because there is not enough memory to allocate
 another file control block (FCB). A FCB must be allocated from the
 heap for each file opened. Try using the /Gt switch, which frees up
 space in the default data segment and allows more room for the near
 heap and consequently the FCBs.


 396. How to Avoid Compiler Error F2220: "Length Redefined"

 Product Version(s): 4.00 4.01 4.10 | 4.10
 Operating System:   MS-DOS         | 4.10
 Flags: ENDUSER |
 Last Modified: 18-AUG-1988    ArticleIdent: Q33996

    The sample program below generates the following compiler error:

    doub.for(9) : error F2220: PA : length redefined

    Function return types must be defined within subprograms that make
 calls to these functions. Within function F1, variable PA must be
 explicitly typed to be double precision to match the previous function
 definition of PA. The error is generated because the default type of
 PA would be REAL*4 or single precision. This process causes the
 compiler error F2220.

    The following sample program demonstrates the problem:

       double precision function pa (w, x)
       w = 1.5
       x = 2.4
       pa = w + x
       return
       end
 C
       double precision function f1 (x)
       f1 = pa (w, x) - sig1
       return
       end

    The function definition of F1 should be as follows:

       double precision function f1 (x)
       double precision pa
       f1 = pa (w, x) - sig1
       return
       end



 397. Benchmarks for Microsoft FORTRAN

 Product Version(s): 4.00 4.01 4.10 | 4.10
 Operating System:   MS-DOS         | OS/2
 Flags: ENDUSER | benchmark
 Last Modified:  7-SEP-1988    ArticleIdent: Q34138

 The following periodicals contain articles that compare the Microsoft
 FORTRAN Optimizing Compiler to other FORTRAN compilers:

 1. November 1987 "Byte Magazine"
 2. July 1988 IEEE "Software Magazine"


 398. L2025 Error: "Symbol Defined More than Once"

 Product Version(s): 4.00 4.01 4.10 | 4.10
 Operating System:   MS-DOS         | OS/2
 Flags: ENDUSER | _main
 Last Modified: 10-AUG-1988    ArticleIdent: Q33998

    When a FORTRAN program generates the link error L2025: "symbol
 defined more than once" occurring on the symbol _main, it usually means
 that more than one of the object modules being linked appeared to the
 linker as a main program.
    Make sure all the subprograms in all object modules, other than the
 main, have the FUNCTION or SUBROUTINE statement.


 399. How to Avoid Compiler Error 803

 Product Version(s): 3.20
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 10-AUG-1988    ArticleIdent: Q33999

 Question:
    When I compile my FORTRAN program I receive an error 803 "Starting
 location is odd." What is wrong with my code?

 Response:
    This error is usually generated by one or more of the following
 conditions:

    1. Characters and reals or integers have been declared in one
       COMMON block. You can reorder the declaration or make the
       character declaration of even type. You can also put the
       character declarations in a different COMMON block than the
       integers and reals.

    2.  An EQUIVALENCE statement was made between a character string
        of odd length with integers or reals.

    Correcting the above situations in your code eliminates the
 compiler error.


 400. Floating-Point Option Causes Error D2011

 Product Version(s): 4.10   | 4.10
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified: 18-AUG-1988    ArticleIdent: Q34270

    It is possible to get the FORTRAN Version 4.10 compiler error
 "D2011 only one floating-point model allowed" when the floating-point
 option is given after the source or object file. This error can occur
 if the FL environment variable contains a source or object file before
 the floating-point option. All options always should occur before
 source and object files on the command line.

    The following is an example of an incorrect FL environment setting:

    SET FL=FL /FPi

    This setting causes the error D2011.
    This error occurs because the compiler assumes that the second FL
 is a filename. Because there is no extension, the compiler assumes
 that "FL" is "FL.OBJ;" as a result, it does not try to compile it.
 Because the filename "FL.OBJ" appears on the command line before the
 /FPi option, the /FPi option does not apply to "FL.OBJ," applying only
 to the file(s) that follow on the command line.
    The "FL.OBJ" is assumed to have the default option /FPi87, so the
 "only one floating-point model allowed" error occurs.
    The error D2011 also can be produced by invoking the compiler using
 the command FL FL /FPi filename.for with no environment variable set.
 Compiling with FL FL /FPi87 filename.for will not produce the error
 because the floating-point option is consistent, /FPi87 is the
 default. (The linker will give an error when it fails to find the
 FL.OBJ file.)
    The correct FL environment setting is as follows:

    SET FL=/FPi


 401. FORTRAN 4.1 F1001 Error in omf_ms.c:1.115, line 1093

 Product Version(s): 4.10 5.00 | 4.10 5.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | buglist4.10 fixlist5.00
 Last Modified:  7-NOV-1989    ArticleIdent: Q34271

 The code below produces the following error, which produces a
 protection violation during compile time under OS/2:

    fatal error F1001:  Internal Compiler Error
                 (compiler file '@(#)omf_ms.c:1.115', line 1093)

 To work around this problem, remove the interface statement.

 Microsoft has confirmed this to be a problem in Version 4.10 of the
 FORTRAN compiler. This problem was corrected in Version 5.00.

 The same internal compiler error is produced when a function, which is
 being passed to another function, is not declared as being EXTERNAL
 inside a subprogram. An example of this process would be a program
 that has Function 1, Function 2, and a subroutine. If Function 2 is
 passed to Function 1 inside the following subroutine, then Function 2
 must be declared inside the subroutine as being EXTERNAL:

    result = Function1 (Function2)

 The workaround to this problem is to make sure the function (Function
 2, in this case) is declared as EXTERNAL.

 The following sample code demonstrates the problem:

        interface to integer function f0 ()
        end

        integer f1, f0, x

        write (*,*) f0()
        x = f1(f0)
        write (*,*) x
        end

        integer function f0 ()
        f0 = 88
        end

        integer function f1 (fx)
        integer fx
        f1 = 12 + fx()
        end


 402. Building LLIBFOR7.LIB Using the Library Manager

 Product Version(s): 4.00 4.01 4.10 | 4.10
 Operating System:   MS-DOS         | OS/2
 Flags: ENDUSER |
 Last Modified: 16-AUG-1988    ArticleIdent: Q34272

    To build the library LLIBFOR7.LIB (large-model, coprocessor-math
 FORTRAN library) the component libraries below must be combined using
 the Library Manager. These libraries should be placed in one directory
 and the PATH environment variable should be set so that the most
 current version of LIB.EXE is in the path. The Library Manager should
 be run from the directory that contains the component libraries.

    The syntax is as follows:

 LIB LLIBFOR7.LIB

 ( the LIB utility will ask you to create ) Y

 OPERATIONS: +LIBH.LIB +LLIBFP.LIB +LLIBFOR.LIB +LLIBFOR1
                   +87.LIB +LCLIB1.LIB

 LIST FILE:  <cr>

 OUTPUT LIBRARY:  <cr>

    At this point, the Library Manager will combine the component
 libraries into the combined library LLIBFOR7.LIB.


 403. F2124 Error Caused by a Real Array Index

 Product Version(s): 4.10 5.00 | 4.10 5.00
 Operating System:   MS-DOS    | OS/2
 Flags: ENDUSER | buglist4.10 fixlist5.00
 Last Modified:  7-NOV-1989    ArticleIdent: Q34328

 The program below generates the following error when compiled with the
 /Od:

    error F2124 : CODE GENERATION ERROR
                Contact Microsoft Technical Support

 In the following sample code, the i variable is used incorrectly in
 the second loop as an integer when it is declared as a real*8. Using a
 real as an array index should cast the real to an integer. If the i
 variable is changed to the j variable, which is defined as an integer,
 the program compiles correctly.

 The following sample code demonstrates the problem:

 c
 c         Main program that generates a code generation error
 c
        complex*16 carr, carr2
        real*8 data,i
        integer nn,isign,j
           dimension carr(128),data(256),carr2(128)
 c
        nn = 128
        isign = 1
 c
        do 100 i = 0.001,0.128,0.001
        carr(i) = dsin(i*360/(2*3.14159))
   100  continue
 c
        do 200 i = 1,128
        data((2*i)-1) = real (carr(i))
        data(2*i) = imag(carr(i))
   200  continue
 c
        stop
        end

 Microsoft has confirmed this to be a problem in Version 4.10 of the
 FORTRAN compiler. This problem was corrected in Version 5.00.


 404. External Data and Public Variables in FORTRAN

 Product Version(s): 4.10 5.00 | 4.10 5.00
 Operating System:   MS-DOS    | OS/2
 Flags: ENDUSER | docerr s_c h_masm s_pascal
 Last Modified: 20-JUN-1990    ArticleIdent: Q34370

 FORTRAN cannot declare individual variables as public. Common blocks
 are the only way to declare publicly accessible variables.

 Section 9.3, "External Data," of the "Microsoft Mixed-Language
 Programming Guide," and Section 5.3.3, "External Data," of the
 "Microsoft FORTRAN Advanced Topics" guide for version 5.00 discuss
 possibilities for shared data. The guide states the following:

    You can always share data between two languages by passing
    parameters. In the case of local variables and all BASIC variables,
    passing parameters is the only convenient way to share data.

    However, C, FORTRAN, and Pascal routines can access data directly
    that are external.

 FORTRAN can access variables declared external in C and Pascal
 routines; however, FORTRAN cannot declare a single variable as public.
 The example on Page 131 of the "Microsoft Mixed-Language Programming
 Guide" and Pages 109-110 of the "Microsoft FORTRAN Advanced Topics"
 incorrectly shows C and Pascal accessing a public variable in the
 FORTRAN routine. This process is impossible because all FORTRAN
 variables are local. Only common blocks and subprogram names are
 public in FORTRAN.

 To declare a variable or set of variables public in FORTRAN, place
 them in a common block. Because common blocks are public, you can
 access the variables through that common block, but not individually.
 For example, you can declare a common block in a FORTRAN program, then
 access that block in a C routine by declaring an external structure
 with the same form.


 405. Opening More than 20 Files under OS/2

 Product Version(s): 4.10
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 10-NOV-1989    ArticleIdent: Q34395

 You cannot open more that 20 files with FORTRAN 4.1 under OS/2. You
 can change this limit in FORTRAN 5.0. See pages 405-407 of the FORTRAN
 5.0 Reference manual for more information.

 FORTRAN 4.1 has the 20 open-files limit hard coded into the compiler.
 This is not a limitation of OS/2, which has the limit of open files at
 255. However, to get the full 20 files in FORTRAN, you must call the
 OS/2 function DosSetMaxFH().

 You cannot open the full 20 files without calling DosSetMaxFH because
 OS/2 opens several files to start. This OS/2 function increases the
 OS/2 file limit. By increasing the OS/2 file limit, the preopened OS/2
 files are freed from the FORTRAN limit of 20 files. Freeing these
 preopened file handles will allow FORTRAN to open 20 files of its own.

 The following program demonstrates how to call DosSetMaxFH to
 open 20 files:

       INTERFACE TO INTEGER*2 FUNCTION DOSSET
      + [ALIAS:'DosSetMaxFH'](fhnum)
       INTEGER*2 fhnum[VALUE]
       END

       INTEGER*2 J, DOSSET
       CHARACTER*12 fname
       fname='FILE   .DAT'
       J = DOSSET(40)

       DO 10, I = 1, 40
       WRITE(fname(5:7),100)I
 100   FORMAT(I3.3)
       OPEN(UNIT=I,FILE=fname,STATUS='NEW',ERR=20)
       WRITE(I,*)fname
 10    CONTINUE
 20    WRITE(*,*) 'cannot open at i=', i
       STOP
       END


 406. Blank Interpretation BN Is the Default

 Product Version(s): 4.00 4.01 4.10 | 4.10
 Operating System:   MS-DOS         | OS/2
 Flags: ENDUSER | docerr
 Last Modified:  7-SEP-1988    ArticleIdent: Q35222

 In section 4.8.1.10 "Blank Interpretation (BN, BZ)" of the "Microsoft
 FORTRAN Optimizing Compiler Language Reference" there is a discussion
 of these two edit descriptors. In the fourth paragraph on Page 132, it
 correctly states that BN is the default. However in the last
 paragraph, on Page 133, it incorrectly states that, "If BZ editing
 were in effect, as it is by default,..."

 This statement is incorrect. BN is the default.


 407. Error F2328 (already typed) should be generated in FORTRAN 4.1

 Product Version(s): 4.10 5.00 | 4.10 5.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | buglist4.10 fixlist5.00
 Last Modified:  7-NOV-1989    ArticleIdent: Q35234

 The following code should produce the error F2328 (already typed) on
 lines 2 and 4, respectively, when using FORTRAN Version 4.10:

       INTEGER A
       INTEGER A
       INTEGER B(10)
       INTEGER B
       END

 However, these errors are not generated. If these variables had been
 declared as reals and not integers, the appropriate errors would have
 been produced.

 Microsoft has confirmed this to be a problem in Version 4.10. This
 problem was corrected in Version 5.00.

 In the following example, "I" gets set to integer in the first
 declaration, so it is actually redefined in the second declaration:

        SUBROUTINE SUB(A,I)
     INTEGER A(I)
     INTEGER I
     END

 In this example, a redefinition error would not be appropriate. The
 compiler should check to see if the variables being typed are dummy
 variables. If the redefined variable is not a dummy variable, then the
 redefinition error F2328 should occur.


 408. Implicit DO within Read May Fail in Certain Cases

 Product Version(s): 4.10   | 4.10
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | buglist4.10 fixlist5.00
 Last Modified:  6-NOV-1989    ArticleIdent: Q35236

 In the example code below, the implicit DO within the read may cause
 the next access to file to fail. The code takes four strings of data
 from a file, but depending on how the data is organized, the program
 may or may not be able to retrieve the last line of data. It does not
 seem to recognize the end-of-record marker in the next-to-last line of
 the data file.

 Microsoft has confirmed this to be a problem in Version 4.10. This
 problem was corrected in version 5.00.

 A work around for this problem is to replace the (A80) with the
 default *.

 The following sample code demonstrates this problem:

       program showbug
       character*8 string(4),last*80
       open (1,file=' ', status='OLD')
       read (1,*) (string(I),I=1,4)
       do 10 i = 1,4
 10      print *,'string(',i,')=',string(i)
       read (1,'(A80)') last
 C     The workaround is to use the following read statement
 C     read (1,*)last
       print *,'last=',last
       stop
       end

 The segment will not retrieve the last line of code if the data is
 organized as follows:

 'one'
 'two'
 'three'
 'four'
 'Last line of text'

 However, if the file is organized as follows, it works correctly:

 'one'
 'two'
 'three' 'four'
 'Last line of text'


 409. Directory Listing for FORTRAN 4.10 Distribution Disks

 Product Version(s): 4.10   | 4.10
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified:  7-SEP-1988    ArticleIdent: Q35237

 Below is a listing of the directories for each of the Microsoft
 FORTRAN Optimizing Compiler Version 4.10 distribution disks (5.25
 inches).

 The information is the resulting output when the DOS command "dir" is
 performed on each directory and subdirectory.

 A line of colons (:::::) separates each disk, and subdirectories are
 listed below their parent directory. The first line of each disk
 description is the name of the disk as it is printed on the label.
 Information in parentheses is supplemental and not contained on the
 disk label.

 The following are directories for FORTRAN Version 4.10 distribution
 disks:

 (Disk 1 of 10)  --  Setup

  Volume in drive A is SETUP
  Directory of  A:\

 DEMOS        <DIR>      2-23-88   9:25a
 PATCH        <DIR>      2-23-88   9:25a
 EMOEM    ASM    12125   2-12-88   2:00p
 F3S      EXE    99308   2-12-88   2:00p
 FL       ERR     1965   2-12-88   2:00p
 FL       EXE    45965   2-18-88   5:33p
 FL       HLP     1726   2-12-88   2:00p
 FLOPSET  DOC     5339   2-12-88   2:00p
 PACKING  LST     8307   2-19-88   4:33p
 PATCH87  EXE     4206   2-12-88   2:00p
 README   DOC    21503   2-22-88  11:53a
 SETUP    DAT    46520   2-12-88   2:00p
 SETUP    EXE    42501   2-22-88  12:24p
        13 File(s)     10240 bytes free

  Volume in drive A is SETUP
  Directory of  A:\DEMOS

 .            <DIR>      2-23-88   9:25a
 ..           <DIR>      2-23-88   9:25a
 CIRC     C       4605   2-23-88   8:30a
 DEMO     FOR     1244   2-23-88   8:30a
 DEMOEXEC FOR      981   2-23-88   8:30a
 DEMORAN  FOR     2940   2-23-88   8:30a
 DWHET    FOR    12463   2-23-88   8:30a
 FOREXEC  INC     5331   2-23-88   8:30a
 GRAPH    BAT      603   2-23-88   8:30a
 GRAPH    FOR     1349   2-23-88   8:30a
 SECNDS   FOR      768   2-23-88   8:30a
 SIEVE    FOR     1440   2-23-88   8:30a
 SWHET    FOR    12312   2-23-88   8:30a
        13 File(s)     10240 bytes free

  Volume in drive A is SETUP
  Directory of  A:\PATCH

 .            <DIR>      2-23-88   9:25a
 ..           <DIR>      2-23-88   9:25a
 README   DOC     1192   2-23-88   8:30a
 RMRHS    EXE      543   2-23-88   8:30a
 SETRHS   EXE      543   2-23-88   8:30a
 STKPAT   BAT       94   2-23-88   8:30a
 STKPAT   SCR       30   2-23-88   8:30a
         7 File(s)     10240 bytes free

 :::::::::::::::::::::::::::::::::::::::

 (Disk 2 of 10)  --  Compiler 1

  Volume in drive A is COMPILER 1
  Directory of  A:\

 F1       ERR    15919   2-23-88   8:30a
 F1       EXE   167017   2-23-88   8:30a
 F3       EXE   155676   2-23-88   8:30a
         3 File(s)     21504 bytes free

 :::::::::::::::::::::::::::::::::::::::

 (Disk 3 of 10)  --  Compiler 2

  Volume in drive A is COMPILER 2
  Directory of  A:\

 EXEC     EXE     9299   2-23-88   8:30a
 F2       EXE   218189   2-23-88   8:30a
 F23      ERR     2967   2-23-88   8:30a
 ILINK    EXE    88929   2-23-88   8:30a
 LIBBUILD BAT    23513   2-23-88   8:30a
         5 File(s)     17408 bytes free

 :::::::::::::::::::::::::::::::::::::::

 (Disk 4 of 10)  --  Utilities

  Volume in drive A is UTILITIES
  Directory of  A:\

 BIND     EXE    36946   2-23-88   8:30a
 ERROUT   EXE    10729   2-23-88   8:30a
 EXEHDR   EXE    29942   2-23-88   8:30a
 EXEMOD   EXE    11765   2-23-88   8:30a
 EXEPACK  EXE    14803   2-23-88   8:30a
 IMPLIB   EXE    30166   2-23-88   8:30a
 LIB      EXE    49661   2-23-88   8:30a
 LINK     EXE   117001   2-23-88   8:30a
 MAKE     EXE    38613   2-23-88   8:30a
 SETENV   EXE    10313   2-23-88   8:30a
        10 File(s)      6144 bytes free

 :::::::::::::::::::::::::::::::::::::::

 (Disk 5 of 10)  --  Microsoft CodeView for MS-DOS

  Volume in drive A is DOSCODEVIEW
  Directory of  A:\

 DEMO     BAT     5512   2-23-88   8:30a
 MOUSE    COM    14455   2-23-88   8:30a
 C_AUTO   CV      2385   2-23-88   8:30a
 E_AUTO   CV      5464   2-23-88   8:30a
 L_AUTO   CV      9631   2-23-88   8:30a
 M_AUTO   CV       721   2-23-88   8:30a
 Q_AUTO   CV        13   2-23-88   8:30a
 S_AUTO   CV      6754   2-23-88   8:30a
 IN       DAT       65   2-23-88   8:30a
 CVREADME DOC    36960   2-23-88   8:30a
 CV       EXE   232896   2-23-88   8:30a
 WHAT     EXE     2434   2-23-88   8:30a
 STATS    FOR     3469   2-23-88   8:30a
 CV       HLP    21552   2-23-88   8:30a
        14 File(s)     10240 bytes free

 :::::::::::::::::::::::::::::::::::::::

 (Disk 6 of 10)  --  Microsoft CodeView for MS OS/2

  Volume in drive A is OS2CODEVIEW
  Directory of  A:\

 CVP      EXE   226591   2-23-88   8:30a
 CVP      HLP    21552   2-23-88   8:30a
 CVPACK   EXE    57437   2-23-88   8:30a
 MAKESORT BAT     1353   2-23-88   8:30a
 MAKESORT CMD     1305   2-23-88   8:30a
 OS2PATCH EXE     1069   2-23-88   8:30a
 PTRACE87 PAT      188   2-23-88   8:30a
 SORTDEMO FOR    29255   2-23-88   8:30a
         8 File(s)     17408 bytes free

 :::::::::::::::::::::::::::::::::::::::

 (Disk 7 of 10)  --  Library (Large Model)

  Volume in drive A is LIBRARIES 1
  Directory of  A:\

 87       LIB     4121   2-23-88   8:30a
 ALTMATH  LIB     7168   2-23-88   8:30a
 EM       LIB    16921   2-23-88   8:30a
 FORTRAN  LIB    34816   2-23-88   8:30a
 LCLIB1   LIB    21893   2-23-88   8:30a
 LIBH     LIB    13673   2-23-88   8:30a
 LLIBFA   LIB    82473   2-23-88   8:30a
 LLIBFOR  LIB    73427   2-23-88   8:30a
 LLIBFOR1 LIB    17539   2-23-88   8:30a
 LLIBFP   LIB    64207   2-23-88   8:30a
 MATH     LIB     6656   2-23-88   8:30a
 NBUILD   OBJ      596   2-23-88   8:30a
        12 File(s)     13312 bytes free

 :::::::::::::::::::::::::::::::::::::::

 (Disk 8 of 10)  --  Library (Medium Model)

  Volume in drive A is LIBRARIES 2
  Directory of  A:\

 87       LIB     4121   2-23-88   8:30a
 EM       LIB    16921   2-23-88   8:30a
 LIBH     LIB    13673   2-23-88   8:30a
 MCLIB1   LIB    21379   2-23-88   8:30a
 MLIBFA   LIB    81449   2-23-88   8:30a
 MLIBFOR  LIB    71891   2-23-88   8:30a
 MLIBFOR1 LIB    17539   2-23-88   8:30a
 MLIBFP   LIB    62669   2-23-88   8:30a
 NBUILD   OBJ      596   2-23-88   8:30a
         9 File(s)     66560 bytes free

 :::::::::::::::::::::::::::::::::::::::

 (Disk 9 of 10)  --  MS OS/2 Libraries

  Volume in drive A is LIBRARIES 3
  Directory of  A:\

 STARTUP      <DIR>      2-23-88   9:35a
 API      LIB    81408   2-23-88   8:30a
 APILMR   OBJ      105   2-23-88   8:30a
 DOSCALLS LIB    29184   2-23-88   8:30a
 LCLIB2   LIB    18833   2-23-88   8:30a
 LLIBFOR2 LIB    18059   2-23-88   8:30a
 MCLIB2   LIB    17809   2-23-88   8:30a
 MLIBFOR2 LIB    17547   2-23-88   8:30a
         8 File(s)      1024 bytes free

  Volume in drive A is LIBRARIES 3
  Directory of  A:\STARTUP

 .            <DIR>      2-23-88   9:35a
 ..           <DIR>      2-23-88   9:35a
 DOS          <DIR>      2-23-88   9:35a
 OS2          <DIR>      2-23-88   9:35a
 BRKCTL   INC      779   2-23-88   8:30a
 CHKSTK   ASM     2036   2-23-88   8:30a
 CHKSUM   ASM     3506   2-23-88   8:30a
 CMACROS  INC    12061   2-23-88   8:30a
 CRT0FP   ASM     2207   2-23-88   8:30a
 MAKEFILE         3113   2-12-88   2:00p
 MSDOS    INC     6087   2-12-88   2:00p
 NULBODY  FOR       11   2-12-88   2:00p
 ONEXIT   ASM     2793   2-12-88   2:00p
 README   DOC     2826   2-12-88   2:00p
 STARTUP  BAT     1407   2-12-88   2:00p
 VERSION  INC      398   2-12-88   2:00p
        16 File(s)      1024 bytes free

  Volume in drive A is LIBRARIES 3
  Directory of  A:\STARTUP\DOS

 .            <DIR>      2-23-88   9:35a
 ..           <DIR>      2-23-88   9:35a
 CRT0     ASM    14422   2-23-88   8:30a
 CRT0DAT  ASM    21296   2-23-88   8:30a
 CRT0MSG  ASM     3055   2-23-88   8:30a
 NMSGHDR  ASM     5132   2-23-88   8:30a
 NULBODY  LNK      156   2-23-88   8:30a
 STDALLOC ASM     3336   2-23-88   8:30a
 STDARGV  ASM    14371   2-23-88   8:30a
 STDENVP  ASM     3692   2-23-88   8:30a
        10 File(s)      1024 bytes free

  Volume in drive A is LIBRARIES 3
  Directory of  A:\STARTUP\OS2

 .            <DIR>      2-23-88   9:35a
 ..           <DIR>      2-23-88   9:35a
 CRT0     ASM    10303   2-23-88   8:30a
 CRT0DAT  ASM    10016   2-23-88   8:30a
 CRT0MSG  ASM     2891   2-23-88   8:30a
 EXECMSG  ASM     2203   2-23-88   8:30a
 NMSGHDR  ASM     3475   2-23-88   8:30a
 NULBODY  LNK      175   2-23-88   8:30a
 STDALLOC ASM     3234   2-23-88   8:30a
 STDARGV  ASM    13612   2-23-88   8:30a
 STDENVP  ASM     5316   2-23-88   8:30a
        11 File(s)      1024 bytes free

 :::::::::::::::::::::::::::::::::::::::

 (Disk 10 of 10)  --  Microsoft Editor

  Volume in drive A is MS EDITOR
  Directory of  A:\

 INI          <DIR>      2-23-88   9:37a
 MSETUP   BAT     2982   2-12-88   2:00p
 FIXSHIFT COM      690   2-23-88   8:30a
 ECH      EXE    19351   2-23-88   8:30a
 EXP      EXE    32220   2-23-88   8:30a
 M        EXE    94821   2-12-88   2:00p
 MEGREP   EXE    31915   2-12-88   2:00p
 MEP      EXE    97063   2-12-88   2:00p
 RM       EXE    24884   2-12-88   2:00p
 UNDEL    EXE    30046   2-12-88   2:00p
 WHAT     EXE     2434   2-12-88   2:00p
        11 File(s)      8192 bytes free

  Volume in drive A is MS EDITOR
  Directory of  A:\INI

 .            <DIR>      2-23-88   9:37a
 ..           <DIR>      2-23-88   9:37a
 BRIEF    INI     2094   2-23-88   8:30a
 EPSILON  INI      978   2-23-88   8:30a
 QUICK    INI     1058   2-23-88   8:30a
 WS       DLL     2609   2-23-88   8:30a
 WS       ZXT     2084   2-23-88   8:30a
         7 File(s)      8192 bytes free


 410. FORTRAN: Complex Expression Causes mactab.c 1.34 Line 639

 Product Version(s): 4.10   | 4.10
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | buglist4.10 fixlist5.00
 Last Modified: 16-JUN-1989    ArticleIdent: Q35265

 The code below causes the following internal compiler error:

 bug.for
 bug.for(7) : fatal error F1001: Internal Compiler Error
                 (compiler file '@(#)mactab.c:1.34', line 639)
                 Contact Microsoft Technical Support

 The workaround for this problem is to simplify the offending line. You
 can use temporary variables, or just simplify the expression. To
 simplify the line, replace the line

 b =-(x/2d0-ima/2d0)

 with the following simplified line:

 b = (ima - x)/2d0

 Microsoft has confirmed this to be a problem in Version 4.10 of the
 FORTRAN compiler. This problem was corrected in Version 5.00.

 The following sample code demonstrates the problem:

       subroutine ose4x4()
       complex*16      ima,x,b,temp1,temp2
       x = (1,0)
       ima = -(1,1)
       b =-(x/2d0-ima/2d0)
       return
       end


 411. How to Clear the Coprocessor Status Word

 Product Version(s): 3.31 4.00 4.01 4.10 | 4.10
 Operating System:   MS-DOS              | OS/2
 Flags: ENDUSER | 8087 80287 80387 80X87 status exception
 Last Modified: 16-JAN-1989    ArticleIdent: Q35434

 Appendix D on Page 359 of the "Microsoft FORTRAN 4.1 Optimizing
 Compiler User's Guide" states the following:

 "When one of the exception conditions occurs, the appropriate bit in
 the status word is set. This flag remains set, indicating that the
 exception occurred, until the user clears it."

 There only is a "load" instruction for the control word (LCWRQQ).

 The status word should be cleared by your interrupt handler. If
 written in C you should use the _clear87() call or _fpreset(). If you
 are using Microsoft's Macro Assembler, you can issue the 8087
 instruction FCLEX directly.

 Unfortunately, just clearing the status word has the potential of
 causing the coprocessor to ignore an interrupt generated at the same
 time as your "clear" instruction.


 412. Calling C Graphics Function _floodfill from a FORTRAN Program

 Product Version(s): 4.10
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist4.10 fixlist5.00
 Last Modified: 19-DEC-1989    ArticleIdent: Q35647

 When calling a C module from a FORTRAN module that draws a box with
 the _lineto function and then _floodfill(s) the box, the _floodfill
 function performs incorrectly. Instead of filling the box with the
 choosen color, _floodfill only draws a horizontal line that intersects
 the point specified in the function call. When the C module is called
 from a C main routine, the function performs correctly.

 To work around this problem, use the _rectangle function with the
 _GFILLINTERIOR option, instead of the _lineto  and _floodfill
 functions.

 Microsoft has confirmed this to be a problem in Version 4.10 of the
 FORTRAN compiler. The problem has been corrected in Version 5.00 of
 the compiler.

 The following program demonstrates the problem (if using a Hercules
 card, make sure to run MSHERC.COM before this program):

 ********************************************************************

 c      FORTRAN Main Module
 c
 c      This program calls a C module that does some graphics.
 c
        interface to subroutine test[c,alias:'_test']
        end
        call test
        stop
        end

 /* This C module draws a box with the upper left coordinates at (0,0)
    and the lower right coordinates at (300,300) by drawing lines.
    It then fills in the box with a color.                          */

 #include "io.h"
 #include "stdio.h"
 #include "graph.h"

 void test (void);

 void  test(void)
 {
    _setvideomode(_HERCMONO);  /* _setvideomode needs to be changed */
    _moveto(0,0);              /* according to your configuration */
    _lineto(300, 0);
    _lineto(300, 300);
    _lineto(0, 300);
    _lineto(0,0);
    _floodfill(132,80, 4);
    getche();
    _setvideomode(_DEFAULTMODE);
  }
 ***********************************************************************


 413. List File Incorrectly Truncates File at Column 72

 Product Version(s): 4.10   | 4.10
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | buglist 4.10 /Fs
 Last Modified:  2-NOV-1988    ArticleIdent: Q35650

 The list (.lst) file from the FORTRAN Version 4.10 Optimizing Compiler
 truncates the .lst file at the 72nd column, instead of column 73 as
 specified on Page 51 in the "Microsoft FORTRAN 4.1 Language Reference
 Guide." This process functions properly on FORTRAN Version 4.00.

 In Version 4.10, the source file compiles correctly, which is evidence
 that the compiler is not truncating the 72nd column. Yet the list file
 is incorrect.

 To work around this problem, use the $LINESIZE metacommand.

 Microsoft has confirmed this to be a problem in Version 4.10. We are
 researching this problem and will post new information as it becomes
 available.


 414. Printing with Control Characters

 Product Version(s): 4.10   | 4.10
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified: 12-JUN-1989    ArticleIdent: Q35867

 In FORTRAN, you can feed control characters directly to the printer
 without printing them.

 The following is a small example that prints the word "Hello", sends a
 form feed to the printer, then prints the word "World":

 OPEN(6, FILE='lpt1', STATUS='old')
 WRITE(6,*) 'HELLO'
 WRITE(6,*) char(12)
 WRITE(6,*) 'WORLD'
 END


 415. Parameter Statement Can't Define Negative Constant

 Product Version(s): 3.30 3.31
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist3.30 buglist3.31 fixlist4.00
 Last Modified: 16-JAN-1989    ArticleIdent: Q35868

 When using parameter to give a constant a symbolic name in FORTRAN
 Versions 3.30 and 3.31, the following statement generates compiler
 error 22: "interger constant expected":

 parameter (x = -0.5)

 However, the following statements do not generate the error message
 when compiling:

 parameter (x = 0.5)  or
 parameter (L = -1)

 Microsoft has confirmed this to be a problem with FORTRAN compiler
 Versions 3.30 and 3.31. This problem was corrected in Version 4.00.


 416. FORTRAN: Open Not Freeing Up Memory During Repetitive Calls

 Product Version(s): 4.01 4.10
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist4.01 buglist4.10 fixlist5.00
 Last Modified: 16-JUN-1989    ArticleIdent: Q35869

 When FORTRAN opens a file, it opens a File Control Block (FCB). When
 it closes the file, the FCB should be freed. However, FORTRAN does not
 free the memory; after numerous openings and closings of PRN, the
 F6700: "heap space limit exceeded" error is generated.

 This problem also occurs with other devices such as CON. This problem
 does not occur with files. The device buffer takes up most of the heap
 space. The default is 1024 bytes.

 To minimize this behavior, use the BLOCKSIZE= option when opening the
 device. The minimum is 512 bytes. This process minimizes the heapspace
 used; however, it doesn't eliminate the problem.

 Microsoft has confirmed this to be a problem in Version 4.01 and 4.10
 of the FORTRAN Compiler. This problem was corrected in Version 5.00.

 The following code demonstrates this problem:

    $STORAGE:2
    $DEBUG
           REAL*4 ARRY(5)

       10  CALL POPEN
           WRITE(2,ERR=8000,IOSTAT=IERR) ARRY
           GOTO 10

     8000  CALL FILERR(IERR)
           END

    C *****************************************
           SUBROUTINE FILERR(IERR)
           IMPLICIT INTEGER*2 (I-N)

           WRITE(*,*) IERR
           END

    C *****************************************
           SUBROUTINE POPEN
           IMPLICIT INTEGER*2 (I-N)
           CLOSE(2)
           OPEN(2,FILE='PRN',FORM='BINARY',ERR=8000,IOSTAT=IERR)
           RETURN

     8000  CALL FILERR(IERR)
           END


 417. Passing Constants to Subroutines in FORTRAN

 Product Version(s): 4.00 4.10 | 4.10
 Operating System:   MS-DOS    | OS/2
 Flags: ENDUSER |
 Last Modified: 30-SEP-1988    ArticleIdent: Q35871

 The code below will generate the following output:

         1.000000
         2.000000

 This behavior is not a problem with Microsoft FORTRAN. The FORTRAN 77
 ANSI standard, section 15.9.2, specifies that when passing a constant
 as an actual argument to a subroutine, the associated dummy argument
 (in this case x) cannot be modified.

 Microsoft FORTRAN does not generate error messages while compiling.
 The above code does not follow the standard; therefore, it will
 generate unpredictable results because FORTRAN passes by reference.

 If the associated dummy argument is going to be modified, pass a
 variable. For example, use "call sub1(y)" with y=1.

 The following code demonstrates this information:

         write (*,*) 1.0
         call sub1(1.0)
         write (*,*) 1.0
         end

         subroutine sub1(x)
         real x
         x = 2.0
         return
         end


 418. Domain and Range of FORTRAN Natural Log Functions

 Product Version(s): 4.00 4.01 4.10  | 4.10
 Operating System:   MS-DOS          | OS/2
 Flags: ENDUSER |
 Last Modified: 30-SEP-1988    ArticleIdent: Q35872

 The program below demonstrates the use of the exp (e**n) and log
 FORTRAN natural logarithm functions, using the limits of real*4 (or
 real) and real*8 values. Both the domain and range of these functions
 must be valid real*4 values for exp and log, and real*8 values for
 dexp and dlog. Consequently, the highest acceptable argument to the
 exp functions is the natural log of the maximum real number for the
 respective floating-point precisions.

 The following demonstrates this information:

 c Program to manipulate natural log and exp functions with greatest and
 c smallest real*4 and real*8 values. The 16th decimal digit displayed
 c exceeds the 15 significant digits, and may not be accurate.

 c Define extreme real*4 and real*8 values, and double- and
 c single-precision "e"

       real*8 maxr8, minr8, pos0r8, neg0r8, e8
       real*4 maxr4, minr4, pos0r4, neg0r4, e4

       maxr8  =  1.7976931348623156d+308
       minr8  = -1.7976931348623156d+308
       pos0r8 =  2.23d-308
       neg0r8 = -2.23d-308
       e8     = dexp(1)

       maxr4  =  1.701411e+38
       minr4  = -1.701411e+38
       pos0r4 =  1.701411e-38
       neg0r4 = -1.701411e-38
       e4     = exp(1)

       write(*,*)
       write(*,*) 'Program to demonstrate use of natural log functions'
       write(*,*) 'with domain & range values at floating point limits.'
       write(*,*)
       write(*,*) 'There are 7 significant decimal digits in a real*4'
       write(*,*) '15 (or 16) significant decimal digits in a real*8.'
       write(*,*)
       write(*,*) 'The Intel coprocessor reference states that the'
       write(*,*) 'range of double precision (real*8) values is'
       write(*,*) 'approximately +/-2.23e-308 to +/-1.80e308. The'
       write(*,*) 'larger real*8 has been carried out to additional'
       write(*,*) 'digits of signifigance below.'
       write(*,*)
       write(*,*) 'Press ENTER to continue...'
       read(*,*)
       write(*,*)
       write(*,*) 'Display extreme real*4 and real*8 values:'
       write(*,*)
       write(*,*) 'max real*8           =  ', maxr8
       write(*,*) 'min real*8           =  ', minr8
       write(*,*) 'smallest positive r8 =  ', pos0r8
       write(*,*) 'smallest negative r8 =  ', neg0r8
       write(*,*)
       write(*,*) 'max real*4           = ', maxr4
       write(*,*) 'min real*4           = ', minr4
       write(*,*) 'smallest positive r4 = ', pos0r4
       write(*,*) 'smallest negative r4 = ', neg0r4
       write(*,*)
       write(*,*) 'Press ENTER to continue...'
       read(*,*)
       write(*,*) 'Perform real*4 and real*8 natural log and'
       write(*,*) 'exponentiation functions on limit values:'
       write(*,*)
       write(*,*) 'dexp(1) = real*8 e   =  ', e8
       write(*,*) 'dlog(maxr8)          =  ', dlog(maxr8)
       write(*,*) 'dexp(dlog(maxr8))    =  ', dexp(dlog(maxr8))
       write(*,*) 'dlog(smallest pos r8)=  ', dlog(pos0r8)
       write(*,*) 'dexp(minr8)          =  ', dexp(minr8)
       write(*,*)
       write(*,*) 'exp(1) = real*4 e    = ', e4
       write(*,*) 'log(maxr4)           = ', log(maxr4)
       write(*,*) 'exp(log(maxr4))      = ', exp(log(maxr4))
       write(*,*) 'log(smallest pos r8) = ', log(pos0r4)
       write(*,*) 'exp(minr4)           = ', exp(minr4)
       write(*,*)
       write(*,*) 'Program completed. Good-bye.'
       end


 419. FORTRAN Code Generation Error with COMPLEX types

 Product Version(s): 4.10
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist4.10 fixlist5.00
 Last Modified:  5-DEC-1989    ArticleIdent: Q35874

 The source code sample below generates the following error:

 wolf1.for(10) : error F2124: CODE GENERATION ERROR
                 Contact Microsoft Technical Support.
 wolf1.for(11) : error F2124: CODE GENERATION ERROR
                 Contact Microsoft Technical Support.

 Microsoft has confirmed this to be a problem in Version 4.10. We are
 researching this problem and will post new information as it becomes
 available.

 To work around this problem, either use the temporary variable I3,
 commented out below, or compile the code with the /Od switch.

 The following sample code demonstrates the problem:

         PROGRAM TEST
 C***************************************************
         COMPLEX*16 c(5,5)
         DOUBLE PRECISION a(5,5)
         INTEGER*2 I1,I2, I3
 C
         DO 1 I1 = 1,5
            DO 2 I2 = 1,5
 c             I3 = I1*I2
               c(I1,I2) = DCMPLX(I1*I2)
               a(I1,I2) = DFLOAT(I1*I2)
   2        CONTINUE
   1     CONTINUE
         STOP
         END


 420. Too Many Errors Cause FORTRAN Compiler to Hang

 Product Version(s): 4.10
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 25-APR-1989    ArticleIdent: Q36400

 A source file consisting of two subroutines, the first with a
 statement out of order, causes the compiler to hang.

 The workaround to this problem is to eliminate the errors and then
 recompile. The errors are due to the code. When this is corrected, the
 routines compile correctly. Please see the figure on Page 55, section
 3.5, "Order of Statements" in the "Microsoft FORTRAN Compiler Language
 Reference."

 Both subroutines compile without hanging if compiled separately.
 However, the first routine generates 38 errors of the following type
 before it exits:

    x1.for(nn) : error F2836: statement out of order

 When both subroutines are in the same source file, the errors show on
 the screen, then the compiler hangs, requiring a warm boot.

 When the DATA statement is placed at the end of the subroutine, where
 the ANSI FORTRAN 77 requires it to be, everything compiles correctly.
 See also the "American National Standard Programming Language FORTRAN,
 ANSI X3.9-1978" Section 3.5.

 The following code demonstrates this problem:

        SUBROUTINE SUB1
 C this subroutine gives many errors due to a line out of order
       INTEGER LAST LINE
       SAVE LAST LINE
 C here is a line out of order
       DATA LAST LINE /-1/
 C normal order resumes
       INTEGER BLANK, ALPHA, DIGIT, LEFTBRACKET, RIGHTBRACKET,
      *   SINGLEQUOTE, DOUBLEQUOTE, COMMA, SLASH, NUMBERSIGN,
      *   AMPERSAND, SEMICOLAN, ASTERIX, EQUALSIGN, OTHER
       PARAMETER (BLANK=1 ,ALPHA=2 ,DIGIT=3 ,
      *         LEFTBRACKET=4, RIGHTBRACKET=5, SINGLEQUOTE=6,
      *         DOUBLEQUOTE=7,COMMA=8, SLASH=9,
      *         NUMBERSIGN=10, AMPERSAND=11, SEMICOLAN=12,
      *         ASTERIX=13, EQUALSIGN=14, OTHER=15)
       CHARACTER NEWBUF(4000)*1,BUFF(4000)*1,IOBUFFER*72,COMMENT*100
       CHARACTER NEWSTR*4000, OLDSTR*4000
       INTEGER LEN,PNBUFF,PBUFF,CHRSET(0:127)
       INTEGER BUFFCODE(4000),$COMMENT,CURRENTLINE
       COMMON /NB1/ NEWBUF
       COMMON /NB2/ LEN,PNBUFF,PBUFF,$COMMENT,CURRENTLINE
       COMMON /NB3/CHRSET
       COMMON /NB4/ BUFFCODE
       COMMON /NB5/ COMMENT
       EQUIVALENCE (NEWBUF(201),BUFF),(NEWSTR,NEWBUF),(OLDSTR,BUFF)
       EQUIVALENCE (BUFF,IOBUFFER)
       INTEGER SCANTO
       LOGICAL AGAIN, DONE
       CHARACTER ALPSTR(40)*1,ALPSTR1*40
       COMMON /LYNLOC1/ SCANTO,AGAIN,DONE
       COMMON /LYNLOC2/ ALPSTR
       EQUIVALENCE (ALPSTR,ALPSTR1)
       INTEGER RECLEN(100),RECIND(100),RECPTR
       COMMON /OLDREC/ RECLEN,RECIND,RECPTR
       CHARACTER * 6  CONTINUE6(19)
       INTEGER  CONTPTR
       COMMON /CON1/ CONTINUE6
       COMMON /CON2/ CONTPTR
       END

       SUBROUTINE SUB2
 C this subroutine will compile if in a separate file
       IMPLICIT LOGICAL (A-Z)
       INTEGER FSTART, START, TAGNUM (200), TAGSTART (1000), I
       INTEGER TAGEND (1000), TAGBEGIN (200), SYMSIZE (200), SMALL
       INTEGER TAGPTR, SYMPTR, CNT, J, K, POINTER, SPACE
       CHARACTER SYMTAB (200)*31, SMALLNAM*31
       INTEGER BLANK, ALPHA, DIGIT, LEFTBRACKET, RIGHTBRACKET,
      *   SINGLEQUOTE, DOUBLEQUOTE, COMMA, SLASH, NUMBERSIGN,
      *   AMPERSAND, SEMICOLAN, ASTERIX, EQUALSIGN, OTHER
       END


 421. F2128: Huge Array Cannot Be Aligned to Segment Boundary

 Product Version(s): 4.00 4.01 4.10 5.00 | 4.10 5.00
 Operating System:   MS-DOS              | OS/2
 Flags: ENDUSER |
 Last Modified: 26-JUL-1990    ArticleIdent: Q36414

 The Microsoft FORTRAN compiler will give the error

    F2128: name : huge array cannot be aligned to segment boundary

 when an array element spans a segment boundary. This error is
 discussed at the top of Page 218 in the Section 9.3.1.2 "Arrays Larger
 than 64K," in the "Microsoft FORTRAN Optimizing Compiler User's Guide"
 for versions 4.x and on Page 32 in the Section 2.3.2.2, "Limits on
 Fixed-Size Arrays Exceeding 64K" in the "Microsoft FORTRAN Advanced
 Topics" manual for version 5.00.

 The workaround for this limitation is to break up the array into
 arrays smaller than two segments, or change the size of the array
 elements to a power of 2 (2**n) bytes so that no elements cross a
 segment boundary.

 The compiler will attempt to offset the start of a huge (larger than
 64K) array so that no array element spans a segment boundary. If a
 huge array is large enough to cross more than one segment boundary
 (larger than 128K), and if the array elements are not a type whose
 size is a power of two, then no possible offset exists that will
 correctly align the array elements with respect to the segment
 boundaries.

 The following code demonstrates this problem:

       CHARACTER*10 TEST(13107)
       END

 This code gives the following error:

    F2128: TEST : huge array cannot be aligned to segment boundary


 422. Unresolved external _cfltcvt_tab with FORTRAN 4.10

 Product Version(s): 4.10   | 4.10
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | S_C
 Last Modified: 25-FEB-1991    ArticleIdent: Q36553

 Question:

 I am getting an error:

     Link : error L2029: Unresolved external __cfltcvt_tab

 Is this an important symbol? How do I resolve it?

 Response:

 There are two instances when you get this unresolved external.
 One is if you are doing mixed language programming between C4.0
 and FORTRAN 4.1 and use any floating point math operations.  The
 other cause can be third party FORTRAN libraries.

 This unresolved external is due to the fact that C Version 4.00 doesn't
 have _cfltcvt_tab but C Versions 5.00 and C 5.10 do. _cfltcvt_tab is not
 necessary, you can still do mixed-language calling or use these FORTRAN
 libraries; you just have to resolve _cfltcvt_tab. You resolve it by
 making a dummy C module that has only one line, as follows:

 char near _cfltcvt_tab[20] = {'0'};

 Compile this and then use the library manager to add this object
 module to your C Version 4.00 library. The command to add it to your
 library is as follows:

 lib llibfp +dummy_c_module;

 (Note: if they do not have our C package your must send them our
 application note that includes this object module.)
 This will take care of your unresolved external and everything
 will work correctly.


 423. Installing In-Line 8087 Instructions

 Product Version(s): 4.00 4.01 4.10 | 4.10
 Operating System:   MS-DOS         | OS/2
 Flags: ENDUSER | docerr appnote S_C
 Last Modified:  7-NOV-1988    ArticleIdent: Q36799

 The assembler code on Page 14 of the "Microsoft FORTRAN 4.1 Update" is
 not correct. When assembled and linked with your FORTRAN application.
 This code will cause divide by zero and overflows to be masked.

 This behavior occurs because the code on Page 14 is incomplete.
 The correct code is listed below. Case is important, so assemble with
 the -Mx switch. You should also link with the /NOE switch. This code
 is provided in line 8087 instructions on FORTRAN Version 4.x and C
 Versions 5.x.

 This application note is also available from Microsoft Product Support
 Services by calling (206) 454-2030.

 ;************************************************************************
 ;rmfixups.asm -
 ;
 ;   Copyright (c) 1988-1988, Microsoft Corporation.  All Rights Reserved.
 ;
 ;Purpose:
 ;  Link with rmfixups.obj in order to prevent floating point instructions
 ;  from being fixed up.
 ;  The case of these names is important so assemble with the -Mx switch.
 ;
 ;*************************************************************************

 public  FIWRQQ,FIERQQ,FIDRQQ,FISRQQ,FJSRQQ,FIARQQ,FJARQQ,FICRQQ,FJCRQQ

 FIDRQQ  EQU     0
 FIERQQ  EQU     0
 FIWRQQ  EQU     0
 FIARQQ  EQU     0
 FJARQQ  EQU     0
 FISRQQ  EQU     0
 FJSRQQ  EQU     0
 FICRQQ  EQU     0
 FJCRQQ  EQU     0

 extrn   __fpmath:far
 extrn   __fptaskdata:far
 extrn   __fpsignal:far

 CDATA   segment word common 'DATA'
         dw      0
         dd      __fpmath
         dd      __fptaskdata
         dd      __fpsignal
 CDATA   ends

 end


 424. Largest REC Value in a WRITE Statement

 Product Version(s): 4.00 4.01 4.10 | 4.10
 Operating System:   MS-DOS         | OS/2
 Flags: ENDUSER |
 Last Modified:  1-DEC-1988    ArticleIdent: Q36800

 In the WRITE statement, the REC parameter is a positive integer
 expression specified for direct access or binary files. The largest
 value for the REC parameter is 32767.

 The REC parameter is discussed in the "Microsoft FORTRAN Optimizing
 Compiler for the MS-DOS Operating System Language Reference" section
 4.3.5, Page 107.


 425. The Standards to Which FORTRAN Version 4.10 Complies

 Product Version(s): 4.10   | 4.10
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | 77
 Last Modified: 11-APR-1989    ArticleIdent: Q36801

 FORTRAN Version 4.10 is certified by the GSA as "error free" with
 respect to ANSI X3.9-1978, which is the FORTRAN77 ANSI standard. Two
 other names for ANSI X3.9-1978 are FIPS PUB 69 and ISO 1539-1980(E),
 so Microsoft conforms to those too.



 426. Loop Optimization with ibset Function

 Product Version(s): 4.00 4.01 | 4.10
 Operating System:   MS-DOS    | OS/2
 Flags: ENDUSER | buglist4.00 buglist4.01 fixlist4.10
 Last Modified:  1-DEC-1988    ArticleIdent: Q36956

 When compiled with loop optimization on, the sample code below does
 not produce the correct output. With loop optimization turned off, the
 program works correctly. Loop optimizaton can be turned off by using
 the compiler option /Od or /Odct.

 The problem occurs when passing to the intrinsic function "ibset", an
 array variable, instead of a variable. If an interger variable is
 passed to "ibset," or if loop optimization is turned off, the program
 works correctly. This behavior is a problem with the loop
 optimization.

 Microsoft has confirmed this to be a problem in Versions 4.00 and
 4.01. This problem was corrected in Version 4.10.

 More Information :

 The following code demonstrates this problem:

         integer*2 isum(2)
         isum(1) = 0

 c    integer i has fixed value 1 through the program
         i = 1

         do 100 k =1,8
         ii = ibset(isum(i),k-1)

 c   substitute the above line with following two lines, the problem
 c   goes away.
 c       jj = isum(i)
 c       ii = ibset(jj,k-1)

         isum(i) = ii
         write(*,*) isum(i),ii
 100     continue
         end


 427. Sample Code Included on the FORTRAN 5.00 Distribution Disks

 Product Version(s): 5.00   | 5.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified: 23-APR-1990    ArticleIdent: Q60980

 The Microsoft FORTRAN Optimizing Compiler Version 5.00 package
 includes many sample programs. Among these are standard FORTRAN
 programs, nearly two dozen sample graphics programs, and a complete
 set of source code for an OS/2 Presentation Manager (PM) application.

 All of the sample programs are on the disk labeled "Source Code."

 The following is a list of the sample code:

 DEMOS Subdirectory  (Demonstration Programs)
 ------------------

    Filename             Description
    --------             -----------

    DEMOEXEC.FOR         FORTRAN demo program (calling a C procedure)
    SWHET.FOR            Popular benchmark program
    EXEC.FI              FORTRAN demo program (include file)
    SIEVE.FOR            Popular benchmark program
    DWHET.FOR            Popular benchmark program
    SORTDEMO.FOR         OS/2 demonstration file

 SAMPLES Subdirectory  (Sample Graphics Programs)
 --------------------

    Filename             Description
    --------             -----------

    REALG.FOR            Chapter 9 graphics example
    SINE.FOR             Chapter 9 graphics example
    COLTEXT.FOR          Chapter 9 graphics example
    CGA.FOR              Chapter 9 graphics example
    EGA.FOR              Chapter 9 graphics example
    HORIZON.FOR          Chapter 9 graphics example
    GRAPHIC.FOR          Chapter 9 graphics example
    COLOR.FOR            Chapter 9 graphics example
    SAMPLER.FOR          Chapter 10 graphics example
    ANIMATE.FOR          Chapter 11 graphics example
    CGAPAL.FOR           Chapter 11 graphics example
    CURSOR.FOR           Chapter 11 graphics example
    FIGURE.FOR           Chapter 11 graphics example
    FILL.FOR             Chapter 11 graphics example
    FONTS.FOR            Chapter 11 graphics example
    MODES.FOR            Chapter 11 graphics example
    PAGE.FOR             Chapter 11 graphics example
    MAGNIFY.FOR          Chapter 11 graphics example
    PALETTE.FOR          Chapter 11 graphics example
    WINDOW.FOR           Chapter 11 graphics example
    SETROWS.FOR          Chapter 11 graphics example
    TEXT.FOR             Chapter 11 graphics example
    WRAP.FOR             Chapter 11 graphics example

 PM Subdirectory  (Sample OS/2 Presentation Manager Program)
 ---------------

    Filename             Description
    --------             -----------

    PMLIST               PMLIST makefile
    PMLIST.DOC           Information about the PMLIST program
    PMLIST.FD            PMLIST declarations include file
    PMLIST.FOR           PMLIST source file
    PMLIST.H             PMLIST header file
    PMLIST.RC            PMLIST resource script file
    PMLIST.DEF           PMLIST definitions file


 428. Internal read of ascii Characters

 Product Version(s): 4.10   | 4.10
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified: 14-NOV-1988    ArticleIdent: Q37075

 The following program

         character*2 dat2
         dat2=#0A
         read(dat2,'(a2)') n
         write(*,600)dat2,n
    600  format(z,' ',z)
         stop
         end

 produces the following output:

    0A00 2020

 When reading from an internal file, the file is treated as a formatted
 sequential file. When the file contains a hexadecimal 0x0A or 0x0D,
 they will be interpreted as a linefeed or carriage return. When they
 are read from a FORMATTED file, they are read as end-of-record markers
 and blanks are used to fill the record.

 This expected behavior is FORTRAN 77 ANSI standard. See the "American
 National Standard Programming Language FORTRAN ANSI X3.9-1978" section
 12.9.5.2.1 paragraph 45. Also, see the "Microsoft FORTRAN Optimizing
 Compiler for the MS-DOS Operating System Language Reference" section
 4.6 "Internal Files" Page 122.


 429. Internal Compiler Error ctypes.c 1.89 Line 1601

 Product Version(s): 4.10   | 4.10
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified: 14-NOV-1988    ArticleIdent: Q37077

 When compiled with loop optimization on, the code below generates the
 following error:

        fatal error F1001 : Internal Compiler Error
        (compiler file '@(#)ctypes.c:1.89', line 1601)
        Contact Microsoft Technical Support

 Microsoft has confirmed this to be a problem in Version FORTRAN 4.10.
 We are researching this problem and will post new information as is
 it becomes available.

 The following code demonstrates this problem:

       call gettim(ihr,imin,isec,i100th)
       b=10.0
       c=2.0
       do 10 i=1,1000
        x1=-b+sqrt(b**2-c)
        x2=-b-sqrt(b**2-c)
        x3=x1**2+2*b*x1+c
        x4=x2**2+2*b*x2+c
        x5=-b-sqrt(b**2-c)
        x6=c/x1
        x7=x1**2+2*b*x1+c
        x8=x2**2+2*b*x2+c
 10    continue
       call gettimn(ihr,imin,isec,i100th)
       stop
       end

 The problem can be avoided by compiling with the /Odct optimization.


 430. Common blocks and Segment Limits in OS/2

 Product Version(s): 4.10
 Operating System:   OS/2
 Flags: ENDUSER |
 Last Modified:  1-NOV-1988    ArticleIdent: Q37267

 A very large FORTRAN program you can compile and link under DOS with
 PLink86, compiles but does not link under OS/2 with the Microsoft
 Linker. Error "L1073 file-segment limit exceeded" is produced. Using
 the /SE switch with a large value to increase number of segments does
 not help.

 Although the 80286 allows a process to have 4095 segments in its local
 descriptor table, OS/2 only allows an application to have 254 physical
 segments. In FORTRAN Version 4.10, each common block is given its own
 physical segment. If a program has many common blocks, it may need
 more than 254 segments. Using the /SE switch to increase the number of
 segments will not work properly because this switch is only for
 logical, not physical, segments.

 Using the /PAC option to pack code segments may help. If it does not,
 the only workaround for this problem is to combine common blocks in
 the program.


 431. Manually Building FORTRAN Run-Time Libraries

 Product Version(s): 4.10 5.00  | 4.10 5.00
 Operating System:   MS-DOS     | OS/2
 Flags: ENDUSER | run-time manual
 Last Modified:  4-DEC-1990    ArticleIdent: Q37268

 To build combined Microsoft FORTRAN libraries, use the Setup program
 to build the libraries. If you have problems running the Setup
 program or want to build the libraries manually using the LIB
 utility, follow the procedures below:

 1. Copy the appropriate files (the contents of either your Large- or
    Medium-Model Libraries Disk) to your hard disk.

 2. Copy LIB.EXE to your current directory or make sure it is in a
    directory listed in your PATH statement.

 3. If you are building an emulator or coprocessor library, perform
    the following (where the question mark is either M for medium model
    or L for large model):

       LIB ?LIBFP.LIB

       Operations: -CVT.OBJ

     If you are building the alternate math library, perform the
     following (where the question mark is either M for medium model or
     L for large model)

       LIB ?LIBFA.LIB

       Operations: -FCCVT.OBJ

 4. Run the library manager to create the appropriate FORTRAN library
    as follows:

       LIB <name of the library you want to build>
       Library does not exist. Create?  <y>
       Operations: <from the operations list below>
       List file: <cr>
       Output library: <cr>

 To build a library with C compatibility, leave out either the
 ?CLIB1.LIB or the ?CLIB2.LIB in the lists of operations that follow.

 The following are the operations for all combinations of the FORTRAN
 libraries. Replace the question marks (?) below with either M for a
 medium-model library or L for a large-model library.

 DOS Libraries
 -------------

 Emulator ?LIBFORE.LIB
    Operations: LIBH.LIB+?LIBFP.LIB+?LIBFOR.LIB&
                ?LIBFOR1.LIB+EM.LIB+?CLIB1.LIB

 Coprocessor ?LIBFOR7.LIB
    Operations: LIBH.LIB+?LIBFP.LIB+?LIBFOR.LIB&
                ?LIBFOR1.LIB+87.LIB+?CLIB1.LIB

 Alternate ?LIBFORA.LIB
    Operations: LIBH.LIB+?LIBFA.LIB+?LIBFOR.LIB&
                ?LIBFOR1.LIB+?CLIB1.LIB

 OS/2 Libraries
 --------------

 Emulator
    Real mode: ?LIBFER.LIB
    Operations: LIBH.LIB+?LIBFP.LIB+?LIBFOR.LIB&
                ?LIBFOR1.LIB+EM.LIB+?CLIB1.LIB

    Protect mode ?LIBFEP.LIB
    Operations: LIBH.LIB+?LIBFP.LIB+?LIBFOR.LIB&
                ?LIBFOR2.LIB+EM.LIB+?CLIB2.LIB

 Coprocessor
    Real mode: ?LIBF7R.LIB
    Operations: LIBH.LIB+?LIBFP.LIB+?LIBFOR.LIB&
                ?LIBFOR1.LIB+87.LIB+?CLIB1.LIB

    Protect mode: ?LIBF7P.LIB
    Operations: LIBH.LIB+?LIBFP.LIB+?LIBFOR.LIB&
                ?LIBFOR2.LIB+87.LIB+?CLIB2.LIB

 Alternate
    Real mode: ?LIBFAR.LIB
    Operations: LIBH.LIB+?LIBFA.LIB+?LIBFOR.LIB&
                ?LIBFOR1.LIB+?CLIB1.LIB

    Protect mode: ?LIBFAP.LIB
    Operations: LIBH.LIB+?LIBFA.LIB+?LIBFOR.LIB&
                ?LIBFOR2.LIB+?CLIB2.LIB

 The ampersand (&) is used for line continuation. If you place all of
 the operations on one line, replace the ampersand with a plus (+).


 432. Assumed-Sized Array Declarator Not Allowed in Common

 Product Version(s): 3.x 4.00 4.01 | 4.10
 Operating System:   MS-DOS        | OS/2
 Flags: ENDUSER | assumed-size adjustable common
 Last Modified:  7-NOV-1988    ArticleIdent: Q37544

 Question :

 I declare an array in a common block in my main FORTRAN program and
 want to reference it in another module. How can I declare the same array
 in a common block with an adjustable size or assumed-size array in the
 other module?

 Response:

 This CANNOT be done. As defined in ANSI standard (ANSI x3.9-1978,
 section 5.1.2), each array declarator is either an actual array
 declarator or a dummy array declarator. An adjustable array declarator
 and an assumed-size array declarator are dummy array declarators. A
 dummy array declarator is not permitted in a COMMON statement.
 Therefore, it is not possible to declare an array with an adjustable
 or assumed size in a common block.

 You may pass the array declared in your main program to a subroutine
 as an argument and declare the argument with an adjustable array
 declarator or assumed-size declarator in a DIMENSION statement.
 Notice, in the example below, the HUGE attribute must be used if the
 array has huge size.

 The following is an example::

 c source file 1
         program test
         common r(32000)
         ....
         call doit(r)
         end

 c source file 2
         subroutine doit (r)
         dimension r[huge](*)
         .....
         return
         end


 433. F6501 Error from Reading Hex 1A in Unformatted Format

 Product Version(s): 4.00
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist4.00 fixlist4.01
 Last Modified: 23-APR-1990    ArticleIdent: Q60982

 The F6501 error "end-of-file encountered" can be generated if a
 record in an unformatted, direct-access file ends with the hex value
 1A.

 Microsoft has confirmed this to be a problem in FORTRAN Version 4.00.
 This problem was corrected in FORTRAN Version 4.01.

 FORTRAN mistakenly generates the F6501 error when an integer*1 is
 given the value 26 (Hex 1A) and is the last value of an unformatted,
 direct-access record. Hex 1A is an end-of-file marker, and FORTRAN
 mistakenly interprets that as an end-of-file marker, thus causing the
 F6501 error.

 The following sample code illustrates the problem:

       integer*1 d(4)
       open(3,file='test.dat',form='unformatted',
      +access='direct',recl=4)
       read(*,*)(d(j),j=1,4)
       write(3,rec=1)(d(j),j=1,4)
       read(3,rec=1)(d(j),j=1,4)
       end

 The input needed to generate the F6501 error is any three numbers
 separated by commas, followed by the number 26. For example, the
 following input to the above program generates the F6501 error:

    1,2,3,26


 434. FORTRAN: /Zi Switch Causes a .MAP File to Be Built

 Product Version(s): 4.00 4.01 4.10 5.00 | 4.10 5.00
 Operating System:   MS-DOS              | OS/2
 Flags: ENDUSER | buglist4.10 fixlist5.00
 Last Modified:  7-NOV-1989    ArticleIdent: Q37636

 When compiling with the Microsoft FORTRAN compiler, the FL driver with
 the /Zi option forces the linker to generate a .MAP file.

 Microsoft has confirmed this to be a problem in Version 4.10. This
 problem was corrected in Version 5.00.

 This problem does not occur with the Microsoft C Compiler Versions
 4.00, 5.00, 5.10, or with the Microsoft Pascal Compiler Version 4.00.


 435. FORTRAN Option /St Fails if in Enviornment Variable

 Product Version(s): 4.10   | 4.10
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified:  1-DEC-1988    ArticleIdent: Q38330

 If the Microsoft FORTRAN Optimizing Compiler Version 4.10 option /St
 is placed in the fl= enviornment variable, the compiler stops the
 subtitle at the first blank space in the quotation marks instead of
 stopping at the closing quotation. It also includes the " as the first
 character of the subtitle.

 The following steps produce the problem:

 1. Set your enviornment variable as follows:

    set fl= /c /Fs /St"some subtitle"

 2. Run the Microsoft FORTRAN Optimizing Compiler Version 4.10 as
    follows:

    fl foo.for

 3. Take a look at your foo.lst file; the subtitle appears as
    follows:

    "some

 To get expected results, e.g. correct subtitles, use the following
 steps:

 1. Run the Microsoft FORTRAN Optimizing Compiler Version 4.10 from the
    command line as follows:

    fl /c /Fs /St"some subtitle" foo.for

 2. Take a look at your foo.lst file, the subtitle appears as follows:

    some subtitle


 436. Accessing System and spawnlp and forexec.inc File.

 Product Version(s): 4.10   | 4.10
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified:  1-DEC-1988    ArticleIdent: Q38332

 The SYSTEM function passes a specified C string to the DOS interpreter
 (COMMAND.COM), which interprets and executes the string as a DOS
 command. The procedure to do this is described on Page 296 in the
 "Microsoft FORTRAN 4.1 Optimizing Compiler User's Guide."

 The manual also states that the INTERFACE statement is required to
 access SYSTEM and _SPAWNLP. Because the INTERFACE statements for these
 two functions are contained in the file forexec.inc (supplied with
 FORTRAN compiler), you can include this file instead of writing the
 INTERFACE statement yourself. The following is an example that uses
 the INCLUDE statement for SYSTEM defined in forexec.inc.

 The following program prints a directory of files in the current
 directory:

 $INCLUDE:'forexec.inc'
       INTEGER*2 SYSTEM
       I = SYSTEM('DIR'C)
       end

 The file forexec.inc is an interface file for C library routines. The
 interface to SYSTEM and _SPAWNLP is defined in the forexec.inc.


 437. Command-Line Switches Require Spaces between Them

 Product Version(s): 4.10   | 4.10
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified:  4-MAY-1989    ArticleIdent: Q43606

 The compiler command-line switches require spaces between them to
 function normally.

 For example, the following command line will execute the compile and
 go directly into the linker, ignoring the /c switch and possibly
 others as well:

    FL/4I2/FPc/Od/c <filename>

 Moving the /c to the front of the command line will result in a
 command-line warning "D4002 ignoring unknown flag," and will continue
 with the compile and link.

 Specifying the line with spaces as shown below will alleviate the
 problem:

    FL /4I2 /FPc /Od /c


 438. Module Name Lost when Compiled with /Gt and /4Yb in FORTRAN

 Product Version(s): 4.00 4.01 4.10 | 4.10
 Operating System:   MS-DOS         | OS/2
 Flags: ENDUSER |  buglist4.00 buglist4.01 buglist4.10 fixlist5.00
 Last Modified:  7-NOV-1989    ArticleIdent: Q38693

 If the /Gt option is used in conjunction with /4Yb or with the $DEBUG
 metacommand when compiling a program with the Microsoft FORTRAN
 Optimizing Compiler, you will get only the line number, instead of
 both module name and line number.

 Microsoft has confirmed this to be a problem in Versions 4.00, 4.01,
 and 4.10. This problem was corrected in Version 5.00.

 The sample program below demonstrates this behavior. Compile with
 /Gt10 and /4Yb. The following sample purposely simulates a R6103
 divide-by-zero run-time error:

       program zerodivide
       real x, y
       x = 5.0
       y = x
       y = y - x
       x = x / y
       end

 Source filenames are stored in DGROUP. When the /Gt option is used, it
 moves out to a different segment. It appears that the problem occurs
 when the numerical argument to /Gt (i.e., /Gt10) is less than the
 length of the source filename plus 6.


 439. FORTRAN Setup on System with Only 5.25-Inch & 3.5-Inch Drives

 Product Version(s): 5.00
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified:  8-JUN-1990    ArticleIdent: Q60983

 Microsoft FORTRAN 5.00 does not have a setup option for systems with
 one 5.25-inch drive and one 3.5-inch drive with no hard drive;
 therefore, the setup must be done manually. Below are the steps needed
 to manually set up FORTRAN on such a system.

 This setup is for running the compiler from your 3.5-inch disk drive
 (Drive B), with the source code on your 5.25-inch disk drive (Drive
 A). Copy the following files from the Setup, Compiler 1, and Compiler
 2 disks onto a single 3.5-inch disk. The files are as follows:

 Setup Disk          Compiler 1 Disk         Compiler 2 Disk
 ----------          ---------------         ---------------

 FL.ERR              F3S.EX                  F2.EXE
 FL.EXE              F1.EXE                  LINK.EXE
 FL.HLP              F1.ERR
 F3.EXE              F23.ERR

 The next step is to manually build the appropriate library that you
 will use to link your FORTRAN modules with. The first step is to
 consult the table titled "Library Build Table" below and copy all of
 these modules (for example, LIBH.LIB and LLIBFP.LIB, etc.) and the
 file LIB.EXE from the Utilities 1 disk onto a single 3.5-inch disk.
 Next, with this 3.5-inch disk in Drive B, do the following:

 1. Type the following from the B:\> prompt

       LIB libraryname.LIB <ENTER>

    where libraryname is the name associated with the type of library
    you are making (for example, LLIBFORE.LIB).

 2. The library manager will prompt you at this point with the
    following:

       LIBRARY DOES NOT EXIST, CREATE ?

 3. Type Y and press ENTER at the prompt.

 4. At this point, the library manager will prompt you with the
    following:

       OPERATIONS:

 5. At the prompt, type the following

       +firstmodule.LIB+secondmodule.LIB+...+lastmodule.LIB <ENTER>

    where FIRSTMODULE.LIB is the name of the first module listed below
    in the LIBRARY BUILD TABLE, SECONDMODULE.LIB is the next, and so
    on.

 6. At this point, the library manager will prompt you with the
    following:

       LIST FILE?

 7. Press ENTER at the prompt.

 8. The library manager will create the library that you named in the
    first step.

 Library Build Table
 -------------------

 Emulator Math Library:  ?LIBFORE.LIB  (where ? is M or L)
      OPERATIONS:    LIBH.LIB+?LIBFP.LIB+?LIBFOR.LIB+
                     ?LIBFOR1.LIB+EM.LIB+?CLIB1.LIB

 Coprocessor Math Library:  ?LIBFOR7.LIB
      OPERATIONS:    LIBH.LIB+?LIBFP.LIB+?LIBFOR.LIB+
                     ?LIBFOR1.LIB+87.LIB+?CLIB1.LIB

 Alternate Math Library:  ?LIBFORA.LIB
      OPERATIONS:    LIBH.LIB+?LIBFA.LIB+?LIBFOR.LIB+
                     ?LIBFOR1.LIB+?CLIB1.LIB

 Note: "M" is for building medium memory model libraries, while "L" is
 for large memory model libraries. "L" is the default.

 The following is an example of building a large-model Emulator Math
 Library:

 1. At the prompt, type the following:

       LIB  LLIBFORE.LIB <ENTER>

 2. The following prompt appears:

       LIBRARY DOES NOT EXIST, CREATE? (y/n)

 3. Type the following:

       Y <ENTER>

 4. The following prompt appears:

       OPERATIONS:

 5. Type the following at the prompt;

       +LIBH.LIB+LLIBFP.LIB+LLIBFOR.LIB+LLIBFOR1.LIB+EM.LIB+LCLIB1.LIB <ENTER>

 6. The following message appears:

       LIST FILE?

 7. Press ENTER.

 At this point, the Library Manager will create a large-model Emulator
 Math library named LLIBFORE.LIB. You then need to copy the library you
 just created onto your 3.5-inch compiler disk. The last part of setup
 involves setting up your environment variables. You need to add the
 following lines to the AUTOEXEC.BAT file that is located on your boot
 disk:

    PATH B:\
    SET LIB=B:\
    SET TMP=B:\
    SET INCLUDE=A:\

 The PATH statement tells the computer where to look for the compiler
 and linker files (here we assume that your 3.5-inch run disk is Drive
 B). The LIB statement tells the computer where your library will be,
 the TMP statement tells the computer where to write its temporary
 files, and the INCLUDE statement tells the computer where to look for
 include files.

 You also need to add the following lines to your CONFIG.SYS
 file:

    FILES=20
    BUFFERS=20


 440. No Utilities and Source Code Disk Shipped with FORTRAN

 Product Version(s):
 Operating System:   4.10   | 4.10
 Flags: MS-DOS | OS/2
 Last Modified: 10-APR-1989    ArticleIdent: Q39066
 ENDUSER | docerr

 Problem:

 Page 20 (section 2.4.3) of the "Microsoft FORTRAN 4.1 Optimizing
 Compiler User's Guide" incorrectly states the following:

    Source programs, including the DEMO.FOR demonstration program on
    the Utilities and Source Code distribution disk...

 This should read as follows:

    Source programs, including the DEMO.FOR demonstration program in
    the DEMOS subdirectory of the Setup distribution disk...

 There is no Utilities and Source Code distribution disk included with
 the FORTRAN package.


 441. Implied List in BLOCK DATA Generates Protection Violation

 Product Version(s): 5.00
 Operating System:   OS/2
 Flags: ENDUSER |
 Last Modified: 16-JUL-1990    ArticleIdent: Q63817

 The Microsoft FORTRAN Compiler version 5.00 generates a "Protection
 Violation" error under OS/2 when compiling the program below with the
 /4Ya switch. This problem does not occur under MS-DOS or in the DOS
 compatibility box of OS/2.

       block data
       integer var(2)
       common /test/ var
       data (var(i),i=1,2) /0, 1/
       end
       end

 This information applies to the Microsoft FORTRAN Compiler version
 5.00 for OS/2.

 The following are the workarounds to avoid the "Protection Violation"
 error:

 1. Do not use the /4Ya compiler option.

 2. Change all implied DO lists to lists of array elements and/or
    variables; for example:

        Change:     data (var(i),i=1,2) /0, 1/
        To:         data var(1), var(2) /0, 1/

 3. Compile the program in MS-DOS or the DOS compatibility box of OS/2.

 More information concerning the BLOCK DATA statement and implied DO
 lists can be found on Pages 123-124 and Page 141, respectively, in the
 "Microsoft FORTRAN Reference" manual.

 Microsoft is researching this problem and will post new information
 here as it becomes available.


 442. Complex Numbers and Error F2112

 Product Version(s): 4.10   | 4.10
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified:  4-MAY-1989    ArticleIdent: Q39068

 You cannot use variables directly while manipulating complex numbers.
 For example, the program below produces the following error:

    Error F2112 : I : not symbolic constant.

 The workaround is to use an intrinsic function CMPLX, as follows:

    Z = CMPLX(I,1.2).

 The following program demonstrates the problem:

 COMPLEX*8 Z
 REAL*4 I
 Z = (I,1.2)
 end

 Page 24 of the "Microsoft FORTRAN Version 4.1 Optimizing Compiler
 Language Reference and Mixed-Language Programmer's Guide" describes
 complex data types as follows:

    The COMPLEX or COMPLEX*8 data type is an ordered pair of single
    precision real numbers. COMPLEX*16 data type is an ordered pair of
    double-precision real numbers. The first number in the pair
    represents the real part of a complex number, and the second number
    represents the imaginary part.

 For example, the complex number (7,3.2) represents the number 7.0+3.2i


 443. FORTRAN Common Blocks Must Have Same Size if Same Name

 Product Version(s): 4.10   | 4.10
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified: 18-APR-1989    ArticleIdent: Q39069

 When you declare a FORTRAN common block and give it the name of a
 previously declared FORTRAN common block, you must be sure that the
 sizes of the two common blocks are exactly the same. If not, you will
 often receive the following error message:

    error F2323: "block name": COMMON: size changed

 This message is ANSI 77 FORTRAN standard as documented in the "American
 National Standard Programming Language FORTRAN" manual on Page 8-4. It
 states the following:

 "Within an executable program, all named common blocks that
 have the same name must be the same size."


 444. Calling C Graphics Routines From FORTRAN Example

 Product Version(s): 4.10
 Operating System:   MS-DOS
 Flags: ENDUSER | S_C S_QUICKC graphics
 Last Modified: 10-APR-1989    ArticleIdent: Q39231

 The Microsoft FORTRAN package does not include a graphics library. One
 effective method of getting Microsoft FORTRAN to do graphics is to
 interface to the graphics library included with either Microsoft
 Optimizing C or QuickC.

 This article presents an example FORTRAN program that demonstrates
 calling the C graphics library from FORTRAN. As written, this example
 will work correctly on a hercules-based system. The modification
 required for other graphics adapters is documented within the program
 below.

 For additional information, query the key words "Graphics For
 FORTRAN" on OnLine.

 The following is an example FORTRAN program:

 c**********************************************************************
 c This is an example FORTRAN program that demonstrates calling C      *
 c graphics library functions.  The interfacing examples presented     *
 c here may be used as a template for calling other graphics library   *
 c functions or other C Run-time Library functions from a FORTRAN      *
 c program.                                                            *
 c                                                                     *
 c To compile and link this program, issue the following command:      *
 c                                                                     *
 c      FL /FPi FGRDEMO.FOR GRAPHICS.LIB /link /NOI                    *
 c                                                                     *
 c The /FPi switch is included for machines that do not have a math    *
 c coprocessor.                                                        *
 c                                                                     *
 c                                                                     *
 c A few caveats of calling C from FORTRAN:                            *
 c                                                                     *
 c  - Every C function being called must have an interface statement   *
 c    because of reasons below.                                        *
 c                                                                     *
 c  - The 'C' attribute must appear in the interface.  This informs    *
 c    FORTRAN to use C calling conventions.                            *
 c                                                                     *
 c  - The alias attribute must appear in the interface.  This serves   *
 c    three purposes:                                                  *
 c     - This allows an underscore to be prepended to function         *
 c       names -- which is consistent with C naming conventions.       *
 c     - FORTRAN, by default, truncates identifiers to six characters. *
 c       An alias allows you to exceed this limit.                     *
 c     - FORTRAN converts all identifiers to uppercase.  An alias      *
 c       gives you the opportunity to declare a function in lower      *
 c       case.  This allows you to preserve case sensitivity during    *
 c       the link phase with /NOI.                                     *
 c                                                                     *
 c  - Any string being passed to C must be a C string (null            *
 c    terminated).                                                     *
 c                                                                     *
 c  - The manifest constants in the C include files are not available  *
 c    to FORTRAN programs.  Whenever a manifest constant is called     *
 c    for, its literal value must be substituted.                      *
 c**********************************************************************

 c
 c     Declare interfaces to C graphics library functions.
 c
       interface to subroutine outtext [C,alias:'__outtext'](string)
       character string [reference]
       end

       interface to integer*2 function setvid[C,alias:'__setvideomode']
      *(mode)
       integer*2 mode
       end

       interface to subroutine rectan [C,alias:'__rectangle']
      *(control,x1,y1,x2,y2)
       integer*2 control,x1,y1,x2,y2
       end

       interface to subroutine setpos [C,alias:'__settextposition']
      *(x,y)
       integer*2 x,y
       end

       Program FGRDEMO
 c
 c Define some variables.
 c
       character*50 greeting
       integer*2    ret
 c
 c The interface statement above is not enough.  We must again
 c state what type 'setvid' will return.
 c
       integer*2    setvid

 c
 c     The C attribute will null terminate this string for passing.
 c
       greeting = 'Hello, world!'C
 c
 c Switch to Hercules graphics mode.  Substitute other values as
 c appropriate (e.g. 16 for EGA/VGA).
 c
       ret = setvid(8)

       if (ret .eq. 0) then
 c
 c If the return value is zero, this mode is not supported.
 c
             write (*,*) 'Selected graphics mode not supported!'
          else
 c
 c Move cursor and display a greeting.
 c
             call setpos (2,5)
             call outtext (greeting)
 c
 c Draw a rectangle.
 c
             call rectan (2,10,5,220,90)
 c
 c Wait for user to hit <ENTER>.
 c
             call setpos (4,5)
             call outtext ('Hit enter to quit:'C)
             read (*,'(A)') ch
 c
 c Go back to the default video mode and terminate.
 c
             ret = setvid (-1)
          endif
       end


 445. Run Time "Please Insert Diskette...", "Cannot Load Overlay..."

 Product Version(s): 3.3x 4.00 4.01 4.10
 Operating System:   MS-DOS
 Flags: ENDUSER | s_link s_c
 Last Modified: 12-JAN-1989    ArticleIdent: Q39335

 When running a FORTRAN Version 3.3x program linked with overlays, the
 following message may be generated:

    Please insert diskette containing PROGNAME.EXE in drive C: and
    strike any key when ready.

 In FORTRAN Versions 4.00, 4.01, and 4.10, the following message may
 appear:

    Cannot load overlay:  too many open files

 The cause is probably a shortage of file handles. The overlay manager
 code didn't have a file handle available for the called overlay. Make
 sure the number of files set in CONFIG.SYS is correct, and close files
 when possible in the program. Resident software (TSR programs) also
 may use up file handles.

 DOS uses up the first five file handles, so the number available to
 the program is five less than the FILES= setting in CONFIG.SYS. If the
 version of DOS is one in which a files setting of greater than 20 is
 not supported (Versions 3.20 or earlier), and if FILES= is set to a
 number greater than 20, the actual files setting may revert to the
 default of 8 handles, leaving only 3 for the FORTRAN program.

 However, even if the DOS is a version that supports a files setting
 greater than 20 (Versions 3.30 and later), the FORTRAN program still
 recognizes only the limit of 20 handles (5 for DOS and 15 for the
 program). It is not possible to cause FORTRAN to recognize more than
 20 file handles.

 If the FILES= setting is correct, then using up all file handles in
 the course of the program will give this message. The program below,
 consisting of three source files, demonstrates this behavior. The
 object modules created from compiling these files should be linked
 using the overlay structure A+(B)+(C).

 The following is the sample program:

 C   This is file A.FOR, the main program.
       OPEN(1, FILE='TEST1')
       OPEN(2, FILE='TEST2')
       OPEN(3, FILE='TEST3')
       OPEN(4, FILE='TEST4')
       OPEN(5, FILE='TEST5')
       OPEN(6, FILE='TEST6')
       OPEN(7, FILE='TEST7')
       OPEN(8, FILE='TEST8')
       OPEN(9, FILE='TEST9')
       OPEN(10, FILE='TEST10')
       OPEN(11, FILE='TEST11')
       OPEN(12, FILE='TEST12')
       OPEN(13, FILE='TEST13')
       OPEN(14, FILE='TEST14')
       OPEN(15, FILE='TEST15')
       CALL X1()
       CALL X2()
       STOP
       END

 C   This is file B.FOR, in the first overlay.
       SUBROUTINE X1()
       WRITE(*,*) 'Here in X1'
       RETURN
       END

 C   This is file C.FOR, in the second overlay.
       SUBROUTINE X2()
       WRITE(*,*) 'Here in X2'
       RETURN
       END


 446. Using Properly Rated Numeric Coprocessors

 Product Version(s): 4.00 4.01 4.10 | 4.10
 Operating System:   MS-DOS         | OS/2
 Flags: ENDUSER | s_c s_quickc s_pascal h_masm b_basiccom b_quickbas
 Last Modified: 18-APR-1989    ArticleIdent: Q39348

 The rated clock speed on coprocessors (8087, 80287, 80387) must be
 greater than or equal to what is recommended on the hardware.
 Otherwise, data integrity will be lost during the use of a
 coprocessor.

 For example, a Compaq 386/20 (20 megahertz) requires a 20 megahertz
 80387 for proper operation. If a floating-point coprocessor rated at a
 slower clock speed is installed, unpredictable results occur. It also
 is possible to damage the coprocessor.

 On some machines, it is not uncommon for the rated speed of the
 numeric coprocessor to be less than the clock speed of the CPU. If you
 do not know the correct coprocessor speed for your machine, check with
 the OEM (Original Equipment Manufacturer) before installing a numeric
 coprocessor.



 447. Bibliography of References for FORTRAN

 Product Version(s): 4.00 4.01 4.10 5.00 | 4.10 5.00
 Operating System:   MS-DOS              | OS/2
 Flags: ENDUSER |
 Last Modified: 14-MAY-1990    ArticleIdent: Q61298

 The following is a list of useful references for FORTRAN programmers.
 This information applies to Microsoft FORTRAN Compiler versions 4.00,
 4.01, 4.10, and 5.00, which follow the ANSI 77 standard. This list can
 also be found on Page xxiv of the "Microsoft FORTRAN Reference" manual
 that comes with FORTRAN version 5.00.  A similar list can be found on
 page 13 of the "Microsoft FORTRAN Compiler User's Guide" for versions
 4.00 and 4.10.

    "Applied FORTRAN 77 featuring Structured Programming"
    by Roy Agelhoff and Richard Mojena,
    published by Wadsworth (1981)

    "Programming with FORTRAN 77"
    by J. Ashcroft, R.H. Eldridge, R.W. Paulson, and G.A. Wilson,
    published by Sheridan House (1981)

    "Problem Solving and Structured Programming in FORTRAN" (2nd ed.)
    by Frank Friedman and E. Koffman,
    published by Addison-Wesley (1981)

    "The Elements of Programming Style"
    by Brian W. Kernighan and P.J. Plauger,
    published by McGraw-Hill (1978)

    "FORTRAN with Style"
    by Henry F. Ledgard and L. Chmura,
    published by Hayden (1978)

    "FORTRAN 77: Principles of Programming"
    by Jerrold L. Wagener,
    published by Wiley (1980)


 448. Optimization Problem, Assignment Not Made, Write Fails

 Product Version(s): 4.10 5.00  | 4.10 5.00
 Operating System:   MS-DOS     | OS/2
 Flags: ENDUSER | buglist4.10 buglist5.00
 Last Modified:  6-NOV-1989    ArticleIdent: Q39514

 The code below produces a loop-optimization problem.

 In DOS, the assignment TMP(I,K)=RBAD(K,I) does not affect the value of
 TMP; it remains 0.0, and you receive the following from the write
 statement:

    F6000F"garbage here"illegal unit number

 In OS/2, the write statement causes a segment violation. The problem
 occurs when the program is compiled as follows:

    FL /FPi /Od /AL  test.for

 Note: Turning ON optimization corrects the problem.

 The following code demonstrates the problem:

       IMPLICIT DOUBLE PRECISION (A-H,O-Z)
       DIMENSION TMP(5000,1)
       COMMON/BAD/RBAD(3,3)
       RBAD(1,1)=1
       CALL TRY1(TMP)
       WRITE(0,*)TMP(1,1)
       END
       SUBROUTINE TRY1(TMP)
       IMPLICIT DOUBLE PRECISION (A-H,O-Z)
       DIMENSION TMP(5000,1)
       COMMON/BAD/RBAD(3,3)
       I=1
       K=1
       TMP(I,K)=RBAD(K,I)
       RETURN
       END

 Microsoft has confirmed to be a problem with the Microsoft FORTRAN
 Optimizing Compiler Version 4.10 and 5.00. Microsoft is researching
 this problem and will post new information as it becomes available.


 449. Different Defaults for "SHARE=" under DOS and OS/2

 Product Version(s): 4.10   | 4.10
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified: 19-APR-1989    ArticleIdent: Q39515

 The default value of the OPEN statement's "SHARE" argument is
 different under OS/2 protected mode and DOS (or real mode). The
 default value under DOS is "COMPAT"; under OS/2 protected mode it is
 "DENYNONE".


 450. Limit on Number of Assigned GOTO Statements in a Subprogram

 Product Version(s): 4.10 5.00 | 4.10 5.00
 Operating System:   MS-DOS    | OS/2
 Flags: ENDUSER |
 Last Modified:  1-SEP-1989    ArticleIdent: Q39516

 The limit on the number of assigned GOTO statements that can be used
 in any subprogram is 256 in FORTRAN 4.1 and 255 in FORTRAN 5.0.

 If this limit is exceeded, the following error will occur:

      F2842  too many assigned GOTO statements

 This information is documented on Page 23 in Section 6 of the "FORTRAN
 4.1 Update" section of the "Microsoft FORTRAN 4.1 Optimizing
 Compiler User's Guide" and on page 460 of the FORTRAN 5.0 Reference
 manual.

 There is a documentation error on page 402 of the FORTRAN 5.0
 Reference which indicates the limit to be 64.


 451. Creating Bound Executables with FL

 Product Version(s): 4.10   | 4.10
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified: 12-JAN-1989    ArticleIdent: Q39605

 You can use the FL command to create a bound program (a program that
 runs in either real or protected mode) by using the /Fb command-line
 option. For example, the following command creates a bound executable
 file, BESSELB.EXE, from the source file BESSEL.FOR:

    FL /Lp /FbBESSELB BESSEL.FOR

 Specifying a name causes FL to create a protected-mode executable file
 (BESSEL.EXE) in addition to the bound program (BESSELB.EXE).

 When you omit the extension for the bound program from the name,
 the bound program is automatically given the .EXE extension. If
 you omit the name altogether, the bound program has the same base
 name as the source file, but includes an .EXE extension. No
 protected-mode program is created when you omit the name. Using the /c
 (compile only) option overrides the /Fb option.

 For the /Fb option to work correctly, the files DOSCALLS.LIB,
 APILMR.OBJ, and API.LIB must be in the current directory or in one of
 the directories indicated by the LIB environment variable.

 The file APILMR.OBJ is always bound with the program unless the
 FL command includes the medium-memory model switch. If you are
 doing mixed-language programming using the medium-memory model
 and your routines allocate both near and far memory, you cannot
 bind your program through FL. Use the BIND command directly and
 include the /n switch and APILMR.OBJ.

 If you are binding mixed-language executable files that have non-
 Family API calls, you must use the BIND utility directly and include
 the /n switch. Please see Page 10 of the "Microsoft FORTRAN Optimizing
 Compiler for MS OS/2 and MS-DOS Operating Systems Version 4.1 Update"
 and section 5 of the "Microsoft CodeView and Utilities Software
 Development Tools for MS OS/2 and MS-DOS Operating Systems Update."


 452. FORTRAN: SAVE and Procedure and Function Names

 Product Version(s): 4.10   | 4.10
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | buglist4.10 fixlist5.00
 Last Modified: 16-JUN-1989    ArticleIdent: Q39805

 The SAVE function in Microsoft FORTRAN causes variables to retain
 their values between invocations of the procedure in which they are
 defined.

 You cannot use any function or procedure names in the SAVE statement.

 In Microsoft FORTRAN, all function and procedure names are made
 global. The SAVE function forces variables to be static. If you are
 trying to force a global to be static, it will not be allowed.

 When attempting to do this under Microsoft FORTRAN Version 4.10, you
 receive the following error:

    Fatal Error : Error message too long

 This error message is incorrectly generated. Microsoft has confirmed
 this to be a problem in Version 4.10. This problem was corrected in
 Version 5.00.


 453. Declaring an External C Array from FORTRAN

 Product Version(s): 5.x    |  4.x
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | s_c H_Fortran
 Last Modified: 19-APR-1989    ArticleIdent: Q39850

 If a FORTRAN module wants to access a C array, it must place the index
 of the array after the C external naming convention.

 Consider the following array declared in a C module:

    int test[5];

 If accessing this array from a FORTRAN module, the declaration is as
 follows, with the index of the array AFTER the external declaration
 brackets:

    INTEGER*2 TEST [C,EXTERN] (5)       <=== CORRECT

 If the index is placed directly after the variable name, as follows,

    INTEGER*2 TEST(5) [C,EXTERN]        <=== INCORRECT

 the compiler produces the following error:

    F2115   SYNTAX ERROR

 If FORTRAN tries to access any element of the array, such as TEST(1) =
 6, the compiler produces the following error:

    F2515   LEFT SIDE OF ASSIGNMENT ILLEGAL.


 454. Setting an Array Equal to Another Array

 Product Version(s): 5.00   | 5.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified:  9-MAY-1990    ArticleIdent: Q61441

 The quickest and easiest way to set an array equal to another array of
 the same dimension is to just set them equal to each other; that is,
 ARRAY1 = ARRAY2.

 This is a new feature that is non-ANSI Standard. This feature was
 added to FORTRAN version 5.00; therefore, it is not compatible with earlier
 versions of the compiler.

 This information can be found in Section 1.7.5, "Array Expressions,"
 on Page 40 in the "Microsoft FORTRAN Reference" version 5.0 manual.

 Note: You can perform other operations with arrays. See the above
 section of the reference manual for more details.

 The following is an example of setting two arrays equal:

       INTEGER ONE(5),TWO(5)

       DATA ONE /1,2,3,4,5/

       TWO=ONE

       WRITE (*,*) ONE(5)
       WRITE (*,*) TWO(5)

       END


 455. Equivalencing Variables in Same Named Common Block

 Product Version(s): 5.00   | 5.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | buglist5.00
 Last Modified: 23-MAY-1990    ArticleIdent: Q61442

 In Microsoft FORTRAN version 5.00, errors are generated when compiling
 a program that uses an EQUIVALENCE statement to associate variables
 declared in the same named common block.

 Under OS/2, a "SYS1943: A program caused a protection violation" error
 occurs.

 Under DOS, a "fatal error : error message too long" error occurs.

 The compiler should generate an "error F2317: VAR2, VAR1 :
 EQUIVALENCE : both in common block COMN" compilation error message
 when compiling the following program:

       PROGRAM HELLO
       COMMON /COMN/ VAR1, VAR2
       EQUIVALENCE (VAR1, VAR2)
       END

 Microsoft is currently researching the problem and will post new
 information here as it becomes available.

 The EQUIVALENCE statement causes two or more variables or arrays to
 occupy the same memory location. More information about the
 EQUIVALENCE statement can be found on Pages 164-166 in the "Microsoft
 FORTRAN Reference" version 5.0 manual.

 Compiler compilation error message F2317 is described on Page 432 of
 the "Microsoft FORTRAN Reference: Error Messages" manual and has the
 following explanation:

    Two items specified in an EQUIVALENCE statement at different
    offsets were both in a named common block. These items were
    specified in the EQUIVALENCE statement to be at the same location
    in memory.


 456. Accessing Command Line Arguments and Finding psp Appnote

 Product Version(s): 4.10   | 4.10
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified: 10-APR-1989    ArticleIdent: Q40097

 The accessing the command line appnote that uses the psp to determine
 the location of the command line arguments in memory do not work
 correctly in the OS/2 operating system. This behavior occurs because
 OS/2 does not implement the psp. This situation also leads to not
 being able to access the environment that is also performed through
 the psp.


 457. FORTRAN Does Not Output ASCII 26 (EOF) to LPTx: or COMx:

 Product Version(s): 3.10 3.13 3.20 3.30 3.31 4.00 4.01 4.10 5.00
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist3.x buglist4.00 buglist4.01 buglist4.10 buglist5.00
 Last Modified:  2-AUG-1989    ArticleIdent: Q44472

 Microsoft FORTRAN Versions 3.x, 4.x, and 5.00 does not output ASCII 26
 (EOF) to LPTx: or COMx: devices. It does output ASCII 26 to a file.
 Because ASCII 26 is nonprintable on most printers, this problem is
 difficult to demonstrate.

 There are two workarounds for this problem:

 1. Send the output to a file and then copy the file to the output
    device desired.

 2. Send the output to the screen and redirect screen output to the
    serial or parallel port.

 Microsoft has confirmed this to be a problem in Versions 3.x, 4.x,
 and 5.00. We are researching this problem and will post new
 information as it becomes available.


 458. Docerr: Passing FORTRAN Strings to BASIC

 Product Version(s): 4.10   | 4.10
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | docerr B_QuickBas B_BasicCom mixed-language
 Last Modified: 10-APR-1989    ArticleIdent: Q40099

 There is an error in the "Microsoft Mixed-Language Programming Guide"
 on Pages 118-119 in the section labeled "Passing FORTRAN Strings to
 BASIC."

 In the documentation, the positions of the address and length are
 reversed. The following sentence is incorrect:

    Next, assign the address of the string to the first element (using
    the LOC function), and assign the length of the string to the
    second element.

 The correct sentence should read as follows:

    Next, assign to the first element the LENGTH of the string, and
    assign the second element the ADDRESS of the string (using the
    LOC function).

 The following programs demonstrate the procedure.
 ----------------------------------------------------------------------

 The Basic main program:

 DECLARE SUB fsub ()

 CALL fsub                               'Call the FORTRAN subroutine
 END

 SUB pass (a$)
   PRINT a$
 END SUB                                 'Print the passed string

 ----------------------------------------------------------------------

 The FORTRAN subprogram:
 c
 c Compile in Medium or Large Memory model
 c
       subroutine fsub()
       character*20 string
       integer*2    sdesc( 2 )

       string = 'hello world !'

       sdesc( 1 ) = 13
       sdesc( 2 ) = loc( string )

       call pass( sdesc )

       end


 459. FORTRAN on Two-Floppy System Does Not Prompt for Next Disk

 Product Version(s): 4.10   | 4.10
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | dual floppy docerr
 Last Modified: 11-APR-1989    ArticleIdent: Q40100

 According to Page 20 of the "Microsoft FORTRAN Optimizing Compiler for
 MS OS/2 and MS-DOS Operating Systems: Version 4.1 Update Guide," you
 will be "prompted" when you should swap disks when running on a
 two-floppy system. This is not correct. The "prompt" is as follows:

    UNABLE TO EXECUTE F2.EXE, PLEASE ENTER NEW FILESPEC:

 This example is the prompt referred to in the manual. You must enter
 the disk that contains the second pass of the compiler, then type the
 following:

    A:F2.EXE

 The process must then be repeated for F3.EXE.


 460. Invalid Object Module Given when Extension Is Not .FOR

 Product Version(s): 4.10   | 4.10
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | invalid object module
 Last Modified: 12-JAN-1989    ArticleIdent: Q40132

 If you attempt to compile a FORTRAN source that does not end in .FOR,
 an error regarding an invalid object module is generated.

 This is expected behavior. If a file does not have a .FOR extension,
 the compiler will treat it as an object file.  The linker will detect
 this difference and report it as an invalid object module.

 If the compile line is as follows

    fl for100.777

 The complete error message would be as follows:

    Microsoft (R) Segmented-Executable Linker  Version 5.01.21
    Copyright (C) Microsoft Corp 1984-1988.  All rights reserved.

    Object Modules [.OBJ]: FOR100.777
    Run File [FOR100.EXE]: FOR100.EXE
    List File [NUL.MAP]: NUL
    Libraries [.LIB]:
    Definitions File [NUL.DEF]: ;
    FOR100.777 : fatal error L1101: invalid object module
     pos: 1 Record type: 844E

 The workaround to this error is to either rename the program to have a
 .for extension or use the /Tf command line switch to indicate that the
 file is a FORTRAN source file.


 461. FORTRAN Quick Reference Guide Incorrectly Identifies /TF

 Product Version(s): 4.10   | 4.10
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | docerr
 Last Modified: 11-APR-1989    ArticleIdent: Q40135

 The "Microsoft FORTRAN Quick Reference Guide" supplied with FORTRAN
 Version 4.10 incorrectly states that the /TF switch can be used to
 specify a FORTRAN source that does not end with the .for extension.
 However, the correct switch for this is /Tf. This switch is case
 sensitive.


 462. Problem with Floating-Point Accuracy with Minor Code Changes

 Product Version(s): 4.10   | 4.10
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | precision
 Last Modified:  2-MAY-1989    ArticleIdent: Q41017

 If there appears to be a problem with floating-point accuracy with
 minor code changes, it may be due to the optimization of the code. In
 the example below, the change was the addition to the write statement
 in the DO loop.

 The workaround to this problem is to use the /Od switch and add the
 options back on one at a time. In the case below, all options were
 turned back on and the code then compiled perfectly.

 The following is the first example:

        PROGRAM TJ1

        REAL X,Y

        X = 20.00
        XL = 0.0
        DO 10 I = 0, 100
          Y = XL * X
          IF ((Y .GE. 0.0) .AND. (Y .LE. X)) THEN
            WRITE(*,*)'GO IN HERE FOR I = ',I,' Y = ',Y
          ELSE
            WRITE(*,*)'OUCH !!!!, HERE IS THE PROBLEM but Y = ', Y
          ENDIF
          XL = XL + 0.01
 10     CONTINUE
         pause' this one is no good, press a key to continue'

        XL = 1.0
        DO 20 I = 100,0, -1
          Y = XL * X
          IF ((Y .GE. 0.0) .AND. (Y .LE. X)) THEN
            WRITE(*,*)'GO IN HERE FOR I =',I,' Y = ',Y
          ELSE
            WRITE(*,*)'OUCH !!!!, HERE IS THE PROBLEM and Y = ',Y
          ENDIF
          XL = XL - 0.01
 20     CONTINUE

        END

 The following is the second example:

        PROGRAM TJ2

        REAL X,Y

        X = 20.00
        XL = 0.0
        DO 10 I = 0, 100
          Y = XL * X
          IF ((Y .GE. 0.0) .AND. (Y .LE. X)) THEN
            WRITE(*,*)'GO IN HERE FOR I = ',I,' Y = ',Y
          ELSE
            WRITE(*,*)'OUCH !!!!, HERE IS THE PROBLEM but Y = ', Y, 'X = ',X
          ENDIF
          XL = XL + 0.01
 10     CONTINUE
         pause' this one is no good, press a key to continue'

        XL = 1.0
        DO 20 I = 100,0, -1
          Y = XL * X
          IF ((Y .GE. 0.0) .AND. (Y .LE. X)) THEN
            WRITE(*,*)'GO IN HERE FOR I =',I,' Y = ',Y
          ELSE
            WRITE(*,*)'OUCH !!!!, HERE IS THE PROBLEM and Y = ',Y, 'X = ',X
          ENDIF
          XL = XL - 0.01
 20     CONTINUE

        END


 463. Carriage Control Works Correctly Only on Terminal Devices

 Product Version(s): 4.10   | 4.10
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified: 12-JUN-1989    ArticleIdent: Q41018

 Question:

 I would like to write to a disk file using carriage control so that
 the file can be printed later. Can this be done?

 Response:

 Not directly. Carriage control is performed only on a unit that is a
 terminal device. There is no way to have carriage control performed on
 a disk file. To accomplish the same effect, the CHAR function or '/' edit
 descriptor must be used to send the desired control codes.

 For more information, see Page 124 of the "Microsoft FORTRAN 4.1
 Optimizing Compiler: Language Reference."


 464. Read Right Justifies If Alphanumeric Field Width Too Large

 Product Version(s): 4.10   | 4.10
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified: 11-APR-1989    ArticleIdent: Q41019

 Problem:

 When I specify an alphanumeric field in a FORTRAN read format that is
 larger than the variable in which I try to store it, sometimes it
 reads blanks and at other times it doesn't read anything.

 Response:

 This is expected behavior according to the "American National Standard,
 Programming Language FORTRAN," approved April 3, 1978. On Page 13-13 it
 states the following:

 "Let len be the length of the input/output list item. If the specified
 field width w for A input is greater than or equal to len, the
 rightmost len characters will be taken from the input field."

 This means that if the alphanumeric format width is greater than the
 variable in which they will be stored, the read actually starts at
 width - variable length + 1. Therefore, as the example below shows, if
 the input record is shorter than the specified format width, the read
 may appear to read blanks or incorrect data.

 The following program shows this behavior (first create a data file to
 read):

 thisisthefirstlineofthefile
 thisisthesecondlineofthefile
 thisisthethirdlineofthefile
 thisisthelastlineofthefile

 Then type in and compile the following program:

       CHARACTER*20 STUFF
       OPEN(UNIT=1,FILE=' ')
       READ(1,'(A100)') STUFF
       WRITE(*,*) STUFF
       READ(1,'(A10)') STUFF
       WRITE(*,*) STUFF
       READ(1,'(A25)') STUFF
       WRITE(*,*) STUFF
       READ(1,'(A)') STUFF
       WRITE(*,*) STUFF
       CLOSE(1)
       STOP
       END

 When the program is run, the following is the output. The first line
 is blank because it starts to read at 100 - 20 + 1 = column 81, the
 second line gets the first 10 characters, the third line starts at 25
 - 20 + 1 = column 6, and the fourth line contains the first 20
 characters. The following is an example:

    thisisthes
    sthethirdlineofthefi
    thisisthefourthlineo


 465. FORTRAN Compiler Corrupts the Environment

 Product Version(s): 4.01 4.10 | 4.10
 Operating System:   MS-DOS    | OS/2
 Flags: ENDUSER | buglist4.01 buglist4.10 fixlist5.00
 Last Modified: 16-JUN-1989    ArticleIdent: Q41021

 The Microsoft FORTRAN Version 4.10 Optimizing Compiler generates the
 following error message:

    error F2836 : statement out of order

 Then, under DOS, it dumps some garbage control characters and corrupts
 the environment. As a result, DOS commands or programs run after the
 compilation do not behave correctly. Symptoms range from messages such
 as "bad file allocation table on drive C" to the machine hanging upon
 the next invocation of a command. Under Version 4.01, the compiler
 locks up.

 Under OS/2, after the F2836 message is displayed, you receive a
 general protection violation, as follows:

    SYS1942: A program attempted to reference storage outside the
    limits of a stack segment. The program was ended.

 The problem is that the DATA statement precedes the COMMON statement.
 This is not valid FORTRAN code. If the two statements are
 interchanged, the program compiles correctly.

 The following is the sample code that causes these problems:

       program foo
       complex*16 x, c
       data i/ 1 /
       common x(1), n(1,1)
       c=(x(n(1,i)) + x(n(1,1)) ) * ( x(n(1,1)) - x(n(1,1)))
       stop
       end

 Note: Once the DATA and COMMON statements are switched, the following
 line must be inserted before the assignment to the C variable for the
 code to run without a protection violation under OS/2:

       n(1,1) = 1

 Microsoft has confirmed this to be a problem in Versions 4.01 and
 4.10. This problem was corrected in Version 5.00.


 466. DNINT and ANINT Functions May Produce Unexpected Results

 Product Version(s): 4.10 5.00 | 4.10 5.00
 Operating System:   MS-DOS    | OS/2
 Flags: ENDUSER |
 Last Modified:  9-MAY-1990    ArticleIdent: Q61522

 The DNINT and ANINT intrinsic functions may return unexpected results
 if the decimal part of the argument passed is "exactly" 0.5.

 The problem is due to single-bit precision errors that occur because
 some values cannot be exactly represented in IEEE floating-point
 format. This is a limitation of the floating-point format, not a
 limitation of the functions.

 DNINT is an intrinsic FORTRAN function that returns the nearest
 integer value to the given argument. Its argument is a REAL*8, DOUBLE
 PRECISION number and it returns a REAL*8 number. ANINT is the same as
 DNINT except that it also accepts a REAL*4, SINGLE PRECISION argument.

 According to the FORTRAN-77 ANSI Standard, given a value of the form
 m.d, where m is the mantissa and d is the decimal part of the number,
 the following is true:

    if d <  0.5, the number returned should be m, and
    if d >= 0.5, the number returned should be m+1

 When compiled with the /Od switch, the following program demonstrates
 the unexpected results. The value returned is 141.52, where it is
 expected to be 141.53 ( DNINT(14152.5)/100.00 ).

      real*8 result,x,y

      x = 166.50d0
      y =   0.85d0
      result = DNINT(x * y * 100.00) / 100.00
      print *,result

      end

 In the example above, 0.85 could not be represented perfectly, thus
 leading to unexpected results. While the program above demonstrates
 the problem only when optimizations are disabled, this behavior is not
 directly related to optimization.


 467. FORTRAN Logic Precedence Example Error

 Product Version(s): 4.10
 Operating System:   MS-DOS
 Flags: ENDUSER | docerr
 Last Modified:  4-MAY-1989    ArticleIdent: Q41576

 There is a documentation error on Page 47 in the "Microsoft FORTRAN
 4.10 Mixed-Language Programming Guide." On the fourth line from the
 bottom of the page, an example demonstrates precedence in logical
 expressions. The incorrect line reads as follows:

           go = ((.NOT. a) .OR. b) .AND. c

 The line should read as follows:

           go = (.NOT. a) .OR. (b .AND. c)


 468. Floating Point Numbers in Text File Need .0

 Product Version(s): 4.10
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 11-APR-1989    ArticleIdent: Q42358

 If an editor is used to create a data file in which some real numbers
 are to be read, you should always place a ".0" (without the quotation
 marks) after all the numbers to ensure that all numbers are read in
 correctly.

 The following is an example:

 Text File:

 1100110021004100  7576400.0   50000.0    6000.0    8000.0

 FORTRAN Code:

         PROGRAM example

         open(10,file='test.dat',form='formatted')
         read(10,100) a,b,c,d,e,f,g,h
         write(*,*) a,b,c,d,e,f,g,h
 100     format(4(F4.0),4(f10.5))
         close(10)
         end

 If the ".0" were taken off the number 7576400.0, an incorrect value
 would be placed in "h".


 469. CodeView and the $DEBUG Meta Command

 Product Version(s): 4.10   | 4.10
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified: 11-APR-1989    ArticleIdent: Q43066

 If the $DEBUG meta command is used in a FORTRAN program, it can cause
 CodeView to work incorrectly. Symptoms include execution when
 attempting to trace, inability to set either break or watch points,
 and hanging of the system.

 The workaround is to remove to meta command from the code and compile
 using the /Zi switch.


 470. Unresolved External _MAIN or ENTGQQ

 Product Version(s): 4.10   | 4.10
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified: 25-FEB-1991    ArticleIdent: Q43067

 When linking a program in FORTRAN Version 4.10, if the error message
 received is

     Link : error L2029: Unresolved External:  ENTGQQ

 or

     Link : error L2029: Unresolved External:  _main

 This may indicate that the FORTRAN compiler could not identify
 an entry point into the code.


 471. Intrinsic Functions in Substring Evaluation Not Working Right

 Product Version(s): 4.10  5.00  | 4.10  5.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified: 13-JUN-1989    ArticleIdent: Q43068

 The following program does not work correctly (the substring value
 does not evaluate properly):

         program string
         character *20 a,b
         b='abcdefghijklmnop'
         i=2
         j=6
         a=b(i:(i+idim(j,2)))
         write(*,*) a
         end

 The following is a workaround to the problem:

         program string
         character *20 a,b
         b='abcdefghijklmnop'
         i=2
         j=6
         k=i+idim(j,2)
         a=b(i:k)
         write(*,*) a
         end

 The workaround performs all computations with intrinsic functions
 before the substring operation.


 472. /Zi May Not Let Include File Open

 Product Version(s): 4.10   | 4.10
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified: 11-APR-1989    ArticleIdent: Q43069

 Problem:

 When I compile without the /Zi switch, my program compiles correctly.
 If I use the /Zi switch, my program can't open the include files.

 Response:

 The problem exists because not enough FILES have been specified in the
 CONFIG.SYS. The /Zi switch will use a file handle.


 473. D, E, F, and G Edit Descriptors and Integer Input Values

 Product Version(s): 4.00 4.01 4.10 5.00 | 4.10 5.00
 Operating System:   MS-DOS              | OS/2
 Flags: ENDUSER |
 Last Modified:  9-MAY-1990    ArticleIdent: Q61523

 The manner in which FORTRAN's real number edit descriptors (D, E, F,
 and G) handle integer input values may be less than straightforward
 unless the method of interpretation is understood. This method is
 described below.

 The interpretation of integer input is identical for the D, E, F, and
 G edit descriptors. The F edit descriptor is used for the example
 below.

 Syntax: Fw.d

 The input field is w characters wide, with a fractional part d digits
 wide.

 If the decimal point is omitted upon input (that is, the data is an
 integer), the rightmost d digits of the input string, with leading
 zeros assumed if necessary, are interpreted as the fractional part of
 the value represented.

 An example is the following READ statement:

       READ (*, '(F9.4)') xnum

 Input      Number Read
 -----      -----------

 5          .0005
 23456      2.3456
 27         .0027
 -98113     -9.8113
 -286401    -28.6401
 59381      5.9381
 -596E3     -59.6000

 For more information about the real number edit descriptors, see Pages
 90-94 in the "Microsoft FORTRAN Reference" version 5.0 manual, or
 Pages 137-141 of the "Microsoft FORTRAN Language Reference" versions
 4.0 and 4.1 manual.


 474. DPATH Does Not Work for Data Files

 Product Version(s): 4.10
 Operating System:   OS/2
 Flags: ENDUSER | dpath append
 Last Modified: 18-APR-1989    ArticleIdent: Q43292

 When in DOS and using file I/O with FORTRAN Version 4.10, the APPEND
 DOS command allows you to find your data files in other directories.
 However, using the equivalent DPATH command in OS/2 does not work. You
 must specify the proper directory.


 475. INTERFACE Statement May Not Force Data Type Checking

 Product Version(s): 4.10   | 4.10
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified: 18-APR-1989    ArticleIdent: Q43293

 When you use the INTERFACE keyword as in the example below, you must
 remember that data type checking for the specific function or
 subroutine may not be done. In the example below, the fact that the
 main is passing a real that is received as an integer in the function
 is a data mismatch that is not flagged by the compiler. If the
 interface statement is removed, then the data type mismatch is
 flagged.

      INTERFACE TO INTEGER FUNCTION EXAMPLE[C,VARYING] (A,B,C,D)
      INTEGER A,B,C,D
      END

      PROGRAM TEST
      INTEGER W,X,EXAMPLE
      K=EXAMPLE(W,X,Y,Z)
      END

      INTEGER FUNCTION EXAMPLE(E,F,G,H)
      INTEGER E,F,G,H
      EXAMPLE=3
      RETURN
      END


 476. Global Names Can Have Only One Global Definition in Program

 Product Version(s): 3.20 3.30 4.00 4.10 | 3.20 3.30 4.00 4.10
 Operating System:   MS-DOS              | OS/2
 Flags: ENDUSER |
 Last Modified:  2-MAY-1989    ArticleIdent: Q43607

 Because global names are recognized anywhere in a given program, they
 can have only one global definition anywhere in that program. All
 subroutine, function, common-block, and program names are global.

 The compiler recognizes the first six characters of a global name and
 disregards spaces, as in the following examples:

          Program foofar
          common/foofares/I,J,K
          INTEGER*2 I,J,K
          END

 In the above example, you will receive the error message
 "F2325:FOOFAR:COMMON:function or subroutine name".

           Subroutine Paint gate
                   .
                   .
           COMMON/PaintG/I,J,K

 In the above example, you will receive the error message
 "F2325:PAINTG:COMMON: function or subroutine name".


 477. Using Fortran for Floating-Point Exceptions on Clones

 Product Version(s): 4.10   | 4.10
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified:  4-MAY-1989    ArticleIdent: Q43768

 If floating-point exceptions are occurring during run time, there is a
 possible solution provided with FORTRAN. On the Setup disk is a file
 called EMOEM.ASM. This file can be used to modify the floating-point
 exception handler. The description of this file is located in the
 "Microsoft FORTRAN 4.1 Optimizing Compiler: User's Guide" under
 Floating Point Operations, Section 8.5, "Using Non-IBM Compatible
 Computers."

 Please note: Microsoft does not support the modification of this file.
 It is up to the manufacturer of the computer in question to provide
 the necessary modifications to correct any floating-point exceptions.


 478. FORTRAN: Division by .1 Yields Unexpected Result

 Product Version(s): 4.10
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified:  6-NOV-1989    ArticleIdent: Q45092

 The following code yields the expected result of 10 followed by
 significant zeros, as it should for a single-precision real:

                 X = 0
                 Y = 1
                 Z = .1

                 A = (Y - X)/Z
                 WRITE(*,*)' A  = ', A

 (OUTPUT)
           A = 10.000000

 However, if this expression is assigned to an integer as follows, the
 result can be varied:

                 I = (Y - X)/Z
            WRITE(*,*)' I  = ', I

 (OUTPUT)
                 I = 9

 The results are not correct because .1 is a nonterminating fraction in
 binary, and can never be represented exactly. This may result in an
 internal result of 9.99999... for the computation in the computer that
 is then rounded for use with real numbers but truncated at the decimal
 point for use with the integer representation. This is expected
 behavior.


 479. FORTRAN 5.00 Requires OS/2 1.10 or Later

 Product Version(s): 5.00
 Operating System:   OS/2
 Flags: ENDUSER | docerr
 Last Modified:  8-NOV-1989    ArticleIdent: Q45221

 There is a documentation error on Page vi of the "Microsoft FORTRAN
 Getting Started." The text states:

    Operating System and Hardware Requirements...the Microsoft FORTRAN
    Compiler, Version 5.0, operates on any IBM or IBM-compatible
    computer running MS-DOS Version 3.0 or later, or OS/2 Version 1.0
    or later.

 The manual should say that Version 5.00 of the Microsoft FORTRAN
 Compiler requires OS/2 Version 1.10 or later.


 480. Error C1041 Occurs Instead of F1041 in FORTRAN

 Product Version(s): 4.10   | 4.10
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified: 25-MAY-1990    ArticleIdent: Q45616

 FORTRAN version 4.10 may produce the error C1041 and/or the error
 message "Cannot open Compiler Intermediate File" if it does not have
 enough memory to compile. The error should be F1041 rather than C1041.

 This error may also be caused by an incorrectly set TMP environment
 variable or FILES= line in the CONFIG.SYS.

 The TMP environment variable must point to a directory that exists,
 and should not contain spaces around the equals (=) sign. For example,
 the following line points the TMP environment variable to the C:\TMP
 directory:

    SET TMP=C:\TMP

 The FILES= line in the CONFIG.SYS file should be set to a number such
 as 20. If the DOS version you use is earlier than DOS version 3.30 and
 the number of files is set to a number greater than 30, DOS defaults
 to eight. Five files are used by the operating system, so the default
 leaves three for use by the compiler, which may not be enough for any
 working files that must be created. The following line allows 20
 files to be open at one time:

    FILES=20



 481. CodeView Won't Recognize Non-Default File Extensions

 Product Version(s): 5.00
 Operating System:   MS-DOS
 Flags: ENDUSER | S_CodeView
 Last Modified:  8-DEC-1989    ArticleIdent: Q46929

 When debugging a FORTRAN program that has been compiled with a
 "non-.for" extension, CodeView sometimes displays the following
 message:

    Cannot display

 The default FORTRAN source file extension is ".for". CodeView
 uses the extension to determine the language being used. For instance,
 if the source file "test.77" is compiled with the FORTRAN compiler
 (using /Tf to tell the compiler that "test.77" is a FORTRAN file), you
 must ensure that CodeView is also aware that a FORTRAN program is being
 used.

 You can manually select the appropriate language by using the
 pull-down Language menu inside CodeView.

 This problem can occur with any language if the source program has an
 extension different from the default extension for each language (e.g.
 ".for", ".bas", ".c" or ".asm").  You must manually select the
 appropriate language to rectify this problem.

 This problem also can occur with the C compiler, if you use the /Tc
 option to specify that a "non-.c" source file should be accepted. The
 Microsoft FORTRAN compiler will accept a "non-.for" extension on the
 source file if /Tf is used at compile time.


 482. Inline 8087/80287 Assembly Listing Incorrect

 Product Version(s): 5.00   | 5.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | docerr
 Last Modified: 30-NOV-1989    ArticleIdent: Q46961

 The assembly code listing is incorrect on Page 9 of the "Microsoft
 FORTRAN Advanced Topics" manual and on Page 323 of the "Microsoft
 FORTRAN Reference" manual.

 The incorrect information reads as follows:

       extrn  __fpmath:for
       extrn  __fpsignal:for
       extrn  __fptaskdata:for

       CDATA  segment  word  common  'DATA'
              dw  0
              dw  __fpmath
              dw  __fpsignal
              dw  __fptaskdata
       CDATA  ends

       end

 The corrected information should read as follows:

       extrn  __fpmath:far
       extrn  __fpsignal:far
       extrn  __fptaskdata:far

       CDATA  segment  word  common  'DATA'
              dw  0
              dd  __fpmath
              dd  __fpsignal
              dd  __fptaskdata
        CDATA  ends

        end


 483. FORTRAN 5.00 Err Msg: F1901 Program too Large for Memory

 Product Version(s): 5.00   | 5.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified: 24-JUL-1990    ArticleIdent: Q47500

 When compiling a large program using FORTRAN Version 5.00, you may
 receive the following error:

    F1901: program too large for memory

 This error can be caused because the symbol table is too big to be
 placed in NEAR HEAP.

 To correct this problem, perform the following:

 1. Copy F1L.EXE from DISK 13, High Capacity Compiler Disk into the
 \BIN directory.

 2. Compile the program using /B1, as shown in the following example:

    FL /B1 D:\FORTRAN\BIN\F1L.EXE

 The complete pathname and filename must follow the /B1 switch.

 Using the high capacity compiler F1L.EXE to compile the program places
 the symbol table into the FAR HEAP.

 The High Capacity Compiler is documented in the README.DOC file which
 is included on the FORTRAN version 5.00 Setup Disk.


 484. Abbreviation for /INFORMATION Is /INF, Not /I

 Product Version(s): 5.00   | 5.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | docerr
 Last Modified:  6-DEC-1989    ArticleIdent: Q47640

 The following error message can be generated when using the incorrect
 abbreviation for the linker /INFORMATION switch:

    L1001 : I : option name ambiguous

 The "Microsoft FORTRAN 5.0 Quick Reference Guide" incorrectly states
 that the abbreviation for /INFORMATION is /I. The correct switch, as
 listed on page 243 of the "Microsoft FORTRAN 5.0 CodeView and
 Utilities User's Guide" is /INF.


 485. F2037: Asterisk with /4Ys, /4Yi, /4Yv Switches (Syntax Error)

 Product Version(s): 5.00
 Operating System:   MS-DOS
 Flags: ENDUSER | F2037 comment buglist5.00
 Last Modified: 18-OCT-1989    ArticleIdent: Q47722

  Summary:

 The compiler generates the error message "error F2037 : illegal label
 field" when an asterisk is used in Column 1 to indicate a comment line
 with FORTRAN Version 5.00, and you compile with one of the following
 switches:

    Switch     Description
    ------     -----------

    /4Ys       Strict syntax checking
    /4Yi       SAA extensions
    /4Yv       VAX FORTRAN extensions

 This message is incorrect because the asterisk should be allowed to
 indicate a comment.

 To work around this problem, replace the asterisk with a "C".

 Microsoft is researching this problem and will post new information as
 it becomes available.


 486. Suppressing an 8087/80287/80387 Coprocessor with FORTRAN

 Product Version(s): 3.20 4.00 4.01 4.10 5.00 | 4.10 5.00
 Operating System:   MS-DOS                   | OS/2
 Flags: ENDUSER |
 Last Modified:  6-DEC-1989    ArticleIdent: Q47749

 To prevent a FORTRAN program linked with the emulator library from
 using the math coprocessor, modify your environment so the math
 coprocessor is not recognized. You can type in the following line at
 the DOS prompt, or add it to your AUTOEXEC.BAT, and reboot:

    SET NO87=Use of coprocessor suppressed

 If NO87 is set equal to one or more characters, the usage of the
 coprocessor is suppressed. When a program executes and a math
 coprocessor is present, the message "Use of coprocessor suppressed" is
 displayed.

 For more information, consult Page 17 of the "Microsoft FORTRAN 5.0
 Advanced Topics" manual or Page 204 of the FORTRAN 4.X "User's Guide."
 It is listed in the index under Environment Variables, NO87.

 The FORTRAN 3.2 readme.doc also describes the NO87 environment
 variable.


 487. Internal Compiler Error:'@(#)srclist.c:1.59',line 1153

 Product Version(s): 4.10 5.00 | 4.10 5.00
 Operating System:   MS-DOS    | OS/2
 Flags: ENDUSER | buglist5.00
 Last Modified: 18-OCT-1989    ArticleIdent: Q47972

 If a non-existent common block name is placed in a SAVE statement, the
 following F1001 error can occur:

      fatal error F1001: Internal Compiler Error
      (compiler file '@(#)srclist.c:1.59', line 1153)

 To correct the problem, remove the name of the undeclared COMMON
 block.

 The following example demonstrates this situation:

           subroutine subr()
             save /c1/,/test/
             common /c1/ i,j,k
           end

 Remove /test/ from the second line to correct the problem.

 The following error is generated if the subroutine and common block
 have the same name and the /Fs switch is used:

      fatal error F1001: Internal Compiler Error
      (compiler file '@(#)p3io.c:1.93',line 605)


 488. Graphics Routines, Unresolved Externals and FGRAPH.FI & .FD

 Product Version(s): 5.00
 Operating System:   MS-DOS
 Flags: ENDUSER | L2029
 Last Modified: 13-FEB-1990    ArticleIdent: Q48025

 Problem:

 I have FGRAPH.FI at the start of my main file and FGRAPH.FD inside my
 subroutine that is in a separate file. When linking the main and the
 file with the graphics call, the graphics routines get flagged as
 unresolved externals.

 Response:

 Page 138 of the "Microsoft FORTRAN 5.0 Advanced Topics" manual states
 that for every file that makes a graphics call, you must have the
 INTERFACE statements at the beginning of that file (INCLUDE 'FGRAPH.FI').
 You then must include FGRAPH.FD (variable declarations) in every
 subroutine that calls a graphics routine. Note: The INTERFACE statement
 needs to be in EACH FILE in which a graphics routine is called.

 The following examples demonstrate this idea:

 -------EXAMPLE #1-------
 CC  Main program and subroutine in same file:
       INCLUDE 'FGRAPH.FI'   ! interface statements at file beginning
       PROGRAM GRAPH
       CALL DUMMY
       END

       SUBROUTINE DUMMY()
       INCLUDE 'FGRAPH.FD'   ! declarations within the subroutine
       CALL clearscreen( $GCLEARSCREEN )
       RETURN
       END

 -------EXAMPLE #2-------
 CC  Main program in a separate file:
       PROGRAM GRAPH    ! No graphics calls in this file, so include
       CALL DUMMY       ! files are not necessary in this file
       END

 CC  Subroutine in a separate file:
       INCLUDE 'FGRAPH.FI'  ! interface statements at file beginning
       SUBROUTINE DUMMY()
       INCLUDE 'FGRAPH.FD'  ! declarations within the subroutine
       CALL clearscreen( $GCLEARSCREEN )
       RETURN
       END


 489. Using NMAKE to Compile FORTRAN Programs in M Editor in OS/2

 Product Version(s): 5.00
 Operating System:   OS/2
 Flags: ENDUSER | S_EDITOR S_NMAKE
 Last Modified: 16-JUL-1990    ArticleIdent: Q63818

 To compile Microsoft FORTRAN version 5.00 programs using the NMAKE
 utility in the M Editor under OS/2, add the following line to the
 TOOLS.INI file:

    extmake: text nmake /f %s

 This information applies to the Microsoft FORTRAN Compiler version
 5.00 for OS/2, the Microsoft Editor version 1.02 for OS/2, and NMAKE
 version 1.01 for OS/2.

 The NMAKE utility (also known as the Microsoft Program-Maintenance
 Utility) interprets a text file of commands, the description file, to
 compare dates of files and carry out other operations on the basis of
 the comparison. That is, NMAKE will check to see if any of the FORTRAN
 programs listed in the description file have been modified. If any
 have, NMAKE will issue commands to recompile and relink the modified
 programs.

 More information regarding the NMAKE utility and the description file
 required by this utility can be found on Pages 285-306 in the
 "Microsoft CodeView and Utilities User's Guide."

 NMAKE is often utilized to compile and link several FORTRAN programs
 at once. For simplicity, only one FORTRAN program will be used here
 to demonstrate how to use NMAKE to compile FORTRAN programs in the M
 Editor.

 The extmake switch above indicates that the text setting, the %s
 symbol, should be used when a compilation is run. When running a
 compilation you pass the text argument to the COMPILE function and the
 editor executes the NMAKE utility according to this text argument.

 For more information about running a compilation according to the
 extmake switch, see Pages 44-45 in the "Microsoft Editor User's
 Guide."

 NMAKE uses the text argument, %s, as the description file because the
 /F option is used. The /F option specifies that the filename following
 it is the description file to use. Additional information about
 the /F option can be found on Page 287 of the "Microsoft CodeView
 and Utilities User's Guide."

 To compile a FORTRAN program, TEST.FOR, using the NMAKE utility in the
 M Editor under OS/2, do the following:

 1. Invoke the M Editor by typing "MEP TEST.FOR" (without the quotation
    marks) at the OS/2 prompt.

 2. If desired, add the following macro and keystroke definitions  to
    the TOOLS.INI file, and then press ALT+C to generate a compile
    window:

    CompWindow:= savecur home meta down  \   ;open compile log window
                 up up up up arg window  \
                 window arg "<compile>" setfile  \
                 window restcur
    CompWindow: alt+c       ;MACRO open compile window

 3. Run NMAKE according to the extmake switch above by pressing ALT+A,
    entering "MAKEFILE" or the appropriate description filename, and
    pressing SHIFT+F3.

 The following is the description file MAKEFILE for the FORTRAN program
 TEST.FOR:

 all : test
 test.obj : test.for
    fl /c $**
 test : test.obj
    link $**;

 The following is the FORTRAN program TEST.FOR compiled using NMAKE in
 the M Editor:

       write(*,*) ' It works!'
       end

 Compiling FORTRAN programs using the NMAKE utility in the M Editor
 in DOS or the DOS compatibility box of OS/2 is not possible because there
 is not enough memory to load all the files needed. For more
 information on this subject, query in this Knowledge Base on the
 following words:

    D2027 and M EDITOR


 490. FORTRAN Err Msg: F2348: Already Declared SAVE

 Product Version(s): 5.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | buglist5.00 appnote
 Last Modified: 23-JUL-1990    ArticleIdent: Q48624

 The SAVE statement cannot be used on any item more than twice in any
 source file. You will receive a message stating that SAVE is already
 declared.

 This problem has been corrected with an application note which is
 available from Microsoft Product Support Services at (206) 454-2030.
 The application note is called "FORTRAN 5.0 F1.EXE and F1L.EXE
 Patch."

 The following is an example:

          subroutine a
          common /a/
          save /a/
          end

          subroutine b
          common /a/
          save /a/
          end

          subroutine c
          common /a/
          save /a/
          end

 You receive the following message:

    ERROR:

    F2348: a: already declared SAVE



 491. FORTRAN 5.0 Compiler Error F1001: omf_ms.c:1.118, line 1093

 Product Version(s): 5.00   | 5.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | buglist5.00
 Last Modified:  7-NOV-1989    ArticleIdent: Q48632

 The "F1001: omf_ms.c:1.118, line 1093" internal compiler error is most
 often created in FORTRAN 5.0 by passing a structure to a subroutine
 and trying to use an item in that structure in a READ or WRITE operation.

 An application note called "F1.EXE and F1L.EXE PATCH" is available from
 Microsoft Product Support which corrects this problem.

 The following code produces the above error in DOS and produces a
 protection violation under OS/2:

          subroutine a(ms)
          structure /dataset/
            integer*2 number
          end structure

          record /dataset/ ms

          read(*,10) ms.number
  10   format(i2)
          end

 Another way to alleviate this problem is to use a temporary structure,
 as in the following:

          subroutine a(ms)
          structure /dataset/
            integer*2 number
          end structure

          record /dataset/ ms,fs
          read(*,10) fs.number  ! Read into fs which was not passed
          ms=fs                 ! Assign temp struct. to passed struct.
  10      format(i2)
          end


 492. Deallocating Memory to DOS

 Product Version(s): 5.00
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified:  7-DEC-1989    ArticleIdent: Q48636

 When using the DEALLOCATE command with FORTRAN Version 5.00, the
 storage space reserved by ALLOCATE is not returned to the system. Yet,
 the space is free for use inside of the FORTRAN program.

 To clarify Page 143 of the "Microsoft FORTRAN Reference" manual, the
 memory allocated by the ALLOCATE instruction is held by the program
 until the program terminates. The DEALLOCATE instruction frees the
 memory for use inside the main program. The space is not returned to
 DOS.

 If you must have the memory deallocate back to DOS, you can spawn to a
 child process where you ALLOCATE and DEALLOCATE. When the child
 process terminates, the memory that was claimed by the FORTRAN child
 process will be returned to DOS.

 The following code demonstrates this process:

 C----------------------------------------------------------
 C Main file.
 C
       interface to integer*2 function spawnlp
      + [C,VARYING] (mode)
       integer*2 mode
       end
 C
       integer*2 spawnlp
 C
       I=spawnlp(0,loc('child.exe'C),loc('child.exe'C),
      Xint4(0))
       end
 C----------------------------------------------------------

 C----------------------------------------------------------
 C Child process (separate file), called by spawnlp in
 C parent.
 C
       integer size
       character*1 arr1[allocatable] ()
       parameter (size=20000)
 C
       allocate (arr1(size))
       DEALLOCATE (arr1)
       end
 C----------------------------------------------------------


 493. FORTRAN 5.00 Error F2124: CODE GENERATION ERROR

 Product Version(s): 5.00   | 5.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | buglist5.00
 Last Modified: 31-OCT-1989    ArticleIdent: Q48637

 The following code example generates an F2124 ERROR: CODE GENERATION
 ERROR. The error is caused by using an integer as the argument to the
 AINT() function. The code should cause a syntax error because the
 argument for the AINT() function should only be a real.

 The same code compiles with no errors in FORTRAN Version 4.10.

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

          real*4    x,y
          integer*4 i

          x=aint(y)
          y=aint(i)             <--- causes error
          end

 The following functions also generate the F2124 error when compiled
 with FORTRAN 5.0 and an integer is used as a parameter instead of a
 real variable:  AINT(), ANINT(), ASIN(), ACOS(), ATAN(), ATAN2(),
 COTAN(), AND TAN().


 494. First Error Message Doesn't Appear in M

 Product Version(s): 5.00
 Operating System:   MS-DOS
 Flags: ENDUSER | mangled merged message S_EDITOR
 Last Modified: 30-APR-1990    ArticleIdent: Q48638

 The following information is true for MS-DOS only.

 Version 1.02 of the M Editor, which is supplied with FORTRAN version
 5.00, does not display the first error message when compiling a
 FORTRAN version 5.00 program from within M. The M.MSG file displays a
 mixed-up message for the first line. The problem is solved by using
 the /nologo switch for compilation. The compilation line will read as
 follows:

    FL /nologo test.for

 The /nologo switch is an undocumented switch that stops the Microsoft
 copyright logo from appearing when you compile.

 If the Quick or Epsilon configurations have been chosen for the
 Editor, a line must also be added to the TOOLS.INI to define the
 keystrokes for viewing the next error message.

 The following example assigns SHIFT+F3 to NextMsg:

    NextMsg:shift+F3


 495. Library Manager Failure During Installation

 Product Version(s): 5.00   | 5.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | LIB.EXE tmp components manual build
 Last Modified:  6-DEC-1989    ArticleIdent: Q49253

 If the LIBRARY MANAGER fails during installation of the FORTRAN
 product, check for TSRs (terminate-and-stay-resident software) and
 available RAM memory. If your investigation proves sound (no TSRs,
 and as much free memory as possible), but the LIBRARY MANAGER
 continues to fail, you need to build the libraries manually.

 The easiest method is to create a temporary directory on your hard
 disk. Copy the contents of the appropriate library distribution disk
 (Large or Medium Model Libraries Disk) and the file LIB.EXE into this
 directory. LIB.EXE can be found on the Utilities distribution disk.
 You now can create the necessary library without concern for path
 environments or file locations.

 Upon completion, copy the created library into the \LIB directory and
 then delete the contents of the temporary directory.


 496. FORTRAN 5.00 SYSTEM and SPAWNLP Functions

 Product Version(s): 5.00
 Operating System:   MS-DOS
 Flags: ENDUSER | docerr sample demo
 Last Modified:  9-JUL-1990    ArticleIdent: Q48691

 The SYSTEM and SPAWNLP functions are included as part of the FORTRAN
 run-time library. The use of these two functions is demonstrated in a
 program included on the distribution disk labeled SOURCE. The program
 is in the DEMOS directory under the name DEMOEXEC.FOR.

 The comments in this program (and in the include file EXEC.FI)
 incorrectly state that more information is available in Chapter 3 of
 the "Advanced Topics" manual.

 The information is on Page 86 of Chapter 4 of the "Advanced Topics"
 manual under Section 4.2.5.


 497. F2225, NEAR/FAR Attribute Mismatch

 Product Version(s): 4.00 4.10 5.00 | 4.00 4.10 5.00
 Operating System:   MS-DOS         | OS/2
 Flags: ENDUSER | f2225 addressing
 Last Modified:  6-DEC-1989    ArticleIdent: Q48787

 When using FORTRAN in the large model and calling a subroutine that is
 declared as NEAR, error F2225 "NEAR/FAR attribute mismatch" is
 generated if no INTERFACE statement exists for that subroutine.

 When the compiler passes a CALL instruction in a large model FORTRAN
 program, it reserves 4 bytes for the address of the subroutine. If you
 use the NEAR attribute on the subroutine, only 2 bytes are needed for
 the subroutine address.

 The problem occurs because the compiler assumes the subroutine is type
 FAR if the compiler reaches the call to the subroutine before the
 subroutine declaration. If you then specify the subroutine as NEAR,
 you get the attribute mismatch error.

 To eliminate this mismatch, you must use the interface statement at
 the beginning of the file to explicitly define the subroutine as NEAR,
 as shown in the following example:

       interface to subroutine foo [NEAR] ()
       end

 This procedure lets the compiler know that when it comes across a call
 to the subroutine foo, 2 bytes should be reserved for the address
 instead of 4 bytes.


 498. Increasing Maximum Number of Open Files in FORTRAN 5.00

 Product Version(s): 5.00   | 5.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER  | hard-coded
 Last Modified: 10-NOV-1989    ArticleIdent: Q48797

 To increase the limit on the number of open files under FORTRAN
 Version 5.00, follow the steps outlined below. Most of this
 information is also documented on Pages 405-407 of the "Microsoft
 FORTRAN Reference" manual for Version 5.00 and in the file UNIT.ASM,
 which is on the Source Code disk in the STARTUP subdirectory.

 The key point to note in the outline below is that CRT0DAT.ASM must be
 assembled with the following line [where the "l" in /Dmem_l is the
 lowercase letter "l", not the number 1 (one)]:

    MASM /Dmem_l CRT0DAT.ASM

 These alterations require DOS 3.30 or later, or OS/2. The use of
 Microsoft Macro Assembler Version 5.10 or later is also required.

 1. Edit the file CRT0DAT.ASM found on the Source Code disk in the
    \STARTUP\DOS directory (or \STARTUP\OS2 if working under OS/2).

    Change the following line

       _NFILE_=20

    to the following:

    _NFILE_=xx (up to 256)

    You also should delete the comment marks (;) from the following
    lines in CRT0DAT.ASM:

    ;     mov ah,67H
    ;     mov bx,_NFILE_
    ;     callos

    After you delete the comment marks, the lines should read as follows:

       mov ah,67H
       mov bx,_NFILE_
       callos

 2. Edit the UNIT.ASM file on the Source Code disk in the \STARTUP
    directory. Change the following line

       _NFILE_   equ 20

    to the following:

       _NFILE_   equ xx (same as specified in the CRT0DAT.ASM file)

 3. Edit the following line in the CONFIG.SYS file

       FILES=20

    to read as follows:

       FILES=xx (the same number as specified in UNIT.ASM and
                CRT0DAT.ASM files)

    Reboot the machine so the new FILES= statement takes effect.

 4. Assemble the UNIT.ASM and CRT0DAT.ASM files with the following
    lines [note that in mem_l, the last character is the lowercase
    letter "l", not the number 1 (one)]:

       MASM /Dmem_l CRT0DAT.ASM

       MASM UNIT.ASM

 5. Link the .OBJ files with the FORTRAN .OBJ file in the following
    statement:

       LINK /NOE FOO.OBJ + UNIT.OBJ + CRT0DAT.OBJ;

    (where FOO.OBJ is the FORTRAN object code)


 499. /Gt Switch Not Listed in FORTRAN 5.00 Manual Index

 Product Version(s): 4.00 4.10 5.00 | 4.00 4.10 5.00
 Operating System:   MS-DOS         | OS/2
 Flags: ENDUSER | docerr
 Last Modified: 24-JUL-1990    ArticleIdent: Q48866

 The index for the "Microsoft FORTRAN Reference" manual for Version
 5.00 omits the listing for the /Gt Data Threshold switch. Information
 about the /Gt switch can be found on Pages 326-327 in Section 7.6 of
 the manual.

 The manual should have included the index listing under the topic
 "FL options."

 The /Gt switch places data exceeding a specified threshold into the
 far heap.

 The /Gt switch is documented on Page 232 of the "Microsoft FORTRAN
 Optimizing Compiler: User's Guide" for Versions 4.00 and 4.10.

 /Gt is not available in the FORTRAN Versions 3.x (3.10, 3.13, 3.20,
 3.30, and 3.31).


 500. Allocatable Arrays Not Allowed in Structures in FORTRAN 5.00

 Product Version(s): 5.00   | 5.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | docerr
 Last Modified:  6-DEC-1989    ArticleIdent: Q48867

 Page 113 of the "Microsoft FORTRAN Reference" for Version 5.00 states
 that allocatable arrays may not appear in AUTOMATIC, COMMON, DATA, or
 EQUIVALENCE statements. This list is incomplete; it should also
 include STRUCTURES.

 Page 228 of the "Microsoft FORTRAN Reference" for Version 5.00 states
 that "Elements cannot be declared with attributes. For example,
 INTEGER var[FAR] is not permitted." Since allocatable arrays must be
 declared with attributes, they can't be used in structures.


 501. Sample Code on Page 165 in FORTRAN 5.00 Reference Is Correct

 Product Version(s): 4.00 4.01 4.10 5.00 | 4.00 4.01 4.10 5.00
 Operating System:   MS-DOS              | OS/2
 Flags: ENDUSER | docerr
 Last Modified:  6-DEC-1989    ArticleIdent: Q48868

 The sample code on Page 165 of the "Microsoft FORTRAN Reference" for
 Version 5.00 incorrectly states that when you equivalence a real and a
 character array so that the real falls onto an odd byte, the compiler
 generates an error. However, the sample code that is given compiles
 properly.

 The documentation states the following on Page 165 of the "Microsoft FORTRAN
 Reference" manual for Version 5.00 (and Page 211 of the "Microsoft
 FORTRAN Optimizing Compiler: Language Reference" for Versions 4.01 and
 4.10):

    Microsoft FORTRAN permits character and noncharacter entities to be
    associated, but not in such a way that noncharacter entities start
    on an odd-byte boundary. If necessary, the compiler adjusts the
    storage location of the character entity so the noncharacter entity
    begins on an even byte. The following example causes a compile-time
    error:

       CHARACTER 1 char1(10)
       REAL reala, realb
       EQUIVALENCE (reala, char1(1))
       EQUIVALENCE (realb, char1(2))

 (Also note that the asterisk is missing in the character declaration.
 It should read "CHARACTER*1").

 If you compile the above code, not only does it compile properly,
 the following will be true if you create a listing:

 1. char1 has the offset 0000h.

 2. reala has the offset 0000h.

 3. realb has the offset 0001h.

 The equivalence statement appears to work correctly.


 502. F2836: "Statement Out of Order" for DATA Statement

 Product Version(s): 5.00   | 5.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified:  6-DEC-1989    ArticleIdent: Q49730

 The first paragraph on Page 48 of the Version 5.00 "Microsoft FORTRAN
 Reference" states "All specification statements must precede all DATA
 statements, statement-function statements, and executable statements."
 If you do not follow this format, the compiler generates the following
 error message:

    F2836: statement out of order

 The following example generates the "statement out of order" error
 because a DATA statement precedes an integer declaration statement:

       integer n
       data n /1/
       integer m
       end

 The table on Page 47 of the "Microsoft FORTRAN Reference" outlines the
 order that statements must be in for the code to compile correctly.

 Consider the following rules when using the DATA instruction:

 1. The DATA statement must follow COMMON, DIMENSION, EQUIVALENCE,
    EXTERNAL, INTRINSIC, and SAVE instructions.

 2. The DATA statement can work in conjunction with the following:

       Executable statements
       Statement function statements
       ENTRY and FORMAT statements
       All metacommands except the following:

          $DO66,
          $[NO]FLOATCALLS
          $[NO]FREEFORM
          $STORAGE

 3. The DATA statement must follow every other command.

 4. The DATA statement must precede the END instruction.


 503. EXAMPLE Output Incorrect on Page 201 of FORTRAN 5.00 Reference

 Product Version(s): 5.00   | 5.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | docerr
 Last Modified: 24-JUL-1990    ArticleIdent: Q48943

 The EXAMPLE output for the NAMELIST operation on Page 201 of the
 "Microsoft FORTRAN Reference" manual for Version 5.00 is incorrect.

 All NAMELIST interactions require the forward slash (/) to terminate
 the interaction.

 To correct the problem, add a line to the end of the example that
 contains only a forward slash. The example should read as follows:

        &EXAMPLE
        I1 =      11
        I2 =      12

        .
        .
        .

        C10 = '0123456789'
        IARRAY =      41      42      43
        /


 504. Reading Environment Variables from FORTRAN 5.00

 Product Version(s): 5.00
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 23-JAN-1990    ArticleIdent: Q48957

 The program shown below demonstrates how to obtain environment
 variables from the MS-DOS environment. The program calls the C
 getenv() function, which is a built-in part of the FORTRAN Version
 5.00 Library.

 The interface statement and the character function GETENV are the
 required portions, while the main program is for demonstration
 purposes.

 The problem occurs because the C function is designed to return a
 pointer to the contents of the variable. The function does not find
 the variable; it returns a NULL, which causes a problem under FORTRAN
 because there is no way to check for a NULL.

 To correct this problem, you need to look for a variable that does not
 exist. Use the following procedure:

 1. Call getenv() on non-existent variable.

 2. Call getenv(VAR) where VAR is what you want to find.

 3. If the results match, VAR does not exist.

 4. If the results do not match, you have a return value.

 Sample Program
 --------------

        program environment
        character name*20,  string*128, fgetenv*128
        write (*,*) ' Enter name of environment variable'
        read (*,'(A)') name
        string = fgetenv(name)
        write (*,*) 'Value is: ',string
        stop
        end

        interface to character*128 function getenv [c] (var)
        character*21 var [reference]
        end

        character*128 function fgetenv(var)
        character getenv*128, dummy*128, var*20, cvar*21
        integer n
        n = len_trim(var)
        cvar = var(1:n)//char(0)
        fgetenv = char(0)
        dummy = getenv(fgetenv)
        fgetenv = getenv(cvar)
        if (fgetenv.eq.dummy) then
            fgetenv = ' '
        end if
        fgetenv = fgetenv(1:index(fgetenv,char(0)))
        return
        end


 505. VERIFY Function Returns an Integer, Not a Logical

 Product Version(s): 5.00   | 5.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | docerr
 Last Modified:  6-DEC-1989    ArticleIdent: Q48984

 The table of Intrinsic Character Functions on Page 256 of the
 "Microsoft FORTRAN Reference" manual for Version 5.00 incorrectly
 lists the VERIFY function as type logical. The VERIFY function is an
 integer function.

 The examples of the use of the VERIFY function on Pages 257 and 268 of
 the FORTRAN reference correctly show that VERIFY returns an integer.


 506. Syntax, Description of NAMELIST Instruction in FORTRAN 5.00

 Product Version(s): 5.00   | 5.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified:  7-DEC-1989    ArticleIdent: Q49254

 The NAMELIST instruction was introduced in FORTRAN Version 5.00.

 As stated on Page 200 of the "Microsoft FORTRAN Reference" for Version
 5.00, a NAMELIST "declares a group name for a set of variables so they
 may be read or written with a single namelist-directed READ or WRITE
 statement."

    SYNTAX:    NAMELIST /namelst/ varlst [/namelst/ varlst]

 namelst is the name for a group of variables (the name of the
 namelist), and varlst is all the variables in the NAMELIST.

 The main purpose of NAMELIST is to allow you to READ or WRITE groups
 of data with one READ or WRITE instruction.

 When a NAMELIST READ (or WRITE) is performed, the information is read
 (or written) in a specific format. This format has three parts: a
 header, the body, and the terminator. The header consists of the name
 of the NAMELIST preceded by an ampersand (&). The body consists of any
 of the NAMELIST variables you want to READ or WRITE. The terminator is
 a forward slash (/).

 The following code (where "example" is the name of the namelist):

    WRITE (*,example)

 produces output as follows:

 &example
 thischar = 'a'
 numint  = 256
 realval = 3.14
 /

 When reading a NAMELIST, start the READ with the header and then
 explicitly READ each variable. Because a NAMELIST allows you to read
 less then the total number of variables in the list, you must use the
 variable name as you enter the data. This allows the NAMELIST to fill
 that particular variable. If you leave off this assignment, you get
 the run-time error F6511 "variable name not found".

 The following is typical data that would be entered from the keyboard
 in response to the line "READ (*,example)":

 &example
 thischar = 'a'
 numint  = 256
 realval = 3.14
 /

 The header (&example) and terminator (/) must both be entered.


 507. FORTRAN: Internal Compiler Error: @(#)p2symtab.c:1.4 line 939

 Product Version(s): 5.00   | 5.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | buglist5.00
 Last Modified:  6-DEC-1989    ArticleIdent: Q49374

 The code below produces the following error:

  fatal error F1001: Internal Compiler Error
         (compiler file '@(#)p2symtab.c:1.4', line 939)
         Contact Microsoft Technical Support

 The code below should produce a syntax error because, according to the
 last paragraph on Page 135 in the "Microsoft FORTRAN Reference" manual
 for Version 5.00, "An item that appears in 'nlist' cannot be
 initialized in a type statement."

 Code
 ----

          integer*1 a(1,1) /10/
          common /st/a
          end


 508. Spaces Converted to Zeros; BZ Edit Descriptor

 Product Version(s): 5.00
 Operating System:   MS-DOS
 Flags: ENDUSER | docerr BN BZ
 Last Modified:  6-DEC-1989    ArticleIdent: Q49430

 The last paragraph on Page 86 of the "Microsoft FORTRAN Reference"
 manual for Version 5.00 incorrectly states the following:

    ...so the first thing the I/O system does is to pad
    the record 502 on the right with two blanks. If BZ
    editing were in effect, those two blanks would be
    interpreted as zeros,and the record would be equal
    to 50200.

 This is a documentation error. The BZ edit descriptor is designed to
 replace any spaces in the input with zeros, provided the space is not
 a leading space.

 Contrary to Page 86, the I/O system does not pad spaces to the right
 of the two; therefore, the BZ edit descriptor does not add zeros to
 the end of the number.

 With BZ editing, if the user types "502" (without the quotation marks)
 and presses ENTER, the variable that is being read equals 502, not
 50200.

 In contrast, if the user enters "502" followed by two spaces, then
 presses ENTER, the variable is read as 50200.


 509. SPAWNLP and Unresolved External: CLOC

 Product Version(s): 5.00   | 5.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | docerr
 Last Modified:  6-DEC-1989    ArticleIdent: Q49432

 On Page 88 in the "Microsoft FORTRAN Advanced Topics" manual for
 Version 5.00, the code sample for calling SPAWNLP incorrectly has a
 lowercase  "c" on the end of the line. The "c" must be removed to
 properly LINK the program.

 If the "c" is included in the code, you get a link error regarding an
 unknown function called CLOC because the "c" is concatenated with
 "LOC" on the following line.

 The following error is generated:

     error L2029 : 'CLOC' : unresolved external

 The "c" should be removed from the end of the following line:

       I = SPAWNLP(0, LOC('EXEMOD'C), LOC('EXEMOD'C), c
      + LOC('DEMOEXEC.EXE'C), INT4(0))


 510. SHARE Not Installed in OS/2 with FORTRAN 4.10

 Product Version(s): 4.10
 Operating System:   OS/2
 Flags: ENDUSER |
 Last Modified:  6-DEC-1989    ArticleIdent: Q49433

 The following error message incorrectly occurs if a program compiled
 with FORTRAN Version 4.10 is run under OS/2, and if an existing file
 is OPENed as NEW:

    run-time error F6412: OPEN(filename) - SHARE not installed

 The following is the correct error message generated under FORTRAN
 5.00:

    run-time error F6415: OPEN(filename) - file already exists

 The following code demonstrates the problem if the file TRY.DAT
 exists:

        OPEN (1,FILE = 'TRY.DAT',STATUS = 'NEW')
        AB = 15
        WRITE (1,*) AB
        END


 511. Order of C and FORTRAN Libraries at LINK time

 Product Version(s): 5.00   | 5.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | docerr
 Last Modified:  6-DEC-1989    ArticleIdent: Q49446

 In the second paragraph under Specifying Libraries on Page 79 of the
 "Microsoft FORTRAN Advanced Topics" manual for Version 5.00, the
 following statement is made:

    If your program uses both FORTRAN and C, then specify the library
    for the most recent of the two language products first.

 The above information is correct; however, the following later
 sentence is incorrect:

    If you use C 5.1 or later, specify the C library first.

 The FORTRAN 5.00 library should come before the C 5.10 library because
 the FORTRAN 5.00 library is newer. The next line states that you
 should "...make sure you choose a C-compatible library when you
 install FORTRAN."

 In reality, if the FORTRAN is newer than the C, (e.g. FORTRAN 5.00
 being newer than C 5.10), FORTRAN should NOT be installed with C
 compatibility, and the LINK options /NOD and /NOE should be used to
 avoid errors about multiply defined symbols.


 512. /Fo Compiler Switch Moves Only the First Object File

 Product Version(s): 5.00   | 5.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | docerr buglist5.00
 Last Modified: 18-OCT-1989    ArticleIdent: Q49447

 The /Fo compiler switch doesn't produce any error messages; it also
 doesn't work as indicated on Pages 338-339 in the "Microsoft FORTRAN
 Reference" manual for Version 5.00:

    C:\> FL /FoD:\OBJECT\  *.FOR

 The above command line should place all the .obj files in the
 directory OBJECT on the D drive. Instead, it incorrectly places only
 the .obj of the first file it compiles in the directory OBJECT, while
 placing the remainder of the files in the current directory (i.e., the
 root directory on the C drive in the above example).


 513. $PACK Metacommand Syntax Incorrect in FORTRAN 5.00 Manual

 Product Version(s): 5.00   | 5.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | docerr buglist5.00
 Last Modified:  6-DEC-1989    ArticleIdent: Q49450

 Contrary to statements made on Page 305 of the "Microsoft FORTRAN
 Reference" manual for Version 5.00, the syntax for the $PACK
 metacommand must include a colon, as shown in the following:

    $PACK:

 If a colon is not used, the following error occurs:

    F2030: unrecognized metacommand

 The following three documentation errors occur on Page 305:

 1. The first error pertains to the following syntax statement:

       $PACK[:{1|2|3}]

    This incorrect statement shows the colon as an optional character;
    it is not an optional character. It should read as follows:

       $PACK:[{1|2|3}]

    If the colon is left out, the compiler does not recognize "$PACK"
    as a metacommand.

 2. The second-to-last paragraph is also incorrect. It states the
    following:

       If $PACK is specified (no colon or number), packing reverts to
       whatever mode was specified in the command-line /Zp option.

    Because the $PACK metacommand must contain a colon, the sentence
    should instead read something similar to the following:

       If $PACK is specified (without a number)...

 3. In the example, the use of the metacommand is incorrect. The first
    line should read as follows:

       $PACK:


 514. Conditional Compiling with /4cc"string"

 Product Version(s): 4.00 4.01 4.10 5.00 | 4.10 5.00
 Operating System:   MS-DOS              | OS/2
 Flags: ENDUSER |
 Last Modified:  6-DEC-1989    ArticleIdent: Q49451

 /4cc<string> permits conditional compilation of a source file. Page
 335 of the "Microsoft FORTRAN Reference" manual for Version 5.00
 states the following:

    The /4cc option permits conditional compilation of a source file.
    The string is a set of alphabetic characters controlling which
    lines in the source file are to be compiled.

 A similar paragraph is located on page 93 of the FORTRAN 4.00 and 4.10
 User's Guide.

 An example of code that can be conditionally compiled is shown below.

       program test
 L     integer*4 num
 S     integer*2 num
 R     real*4 number
       end

 When compiling this code, if you compile with /4ccL, the compiler
 reserves 4 bytes for num. If you compile with /4ccS, num is 2 bytes.

 If you leave off the /4cc switch, the L, S, and R lines are considered
 comment lines. Or, if you compile with /4ccLS, you get a multiple
 defined symbol error because num is defined twice. /4ccLR or /4ccSR
 define num as the appropriate size, and define number as a real.


 515. Conditional Compilation of Metacommands in FORTRAN 5.00

 Product Version(s): 5.00   | 5.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified:  6-DEC-1989    ArticleIdent: Q49466

 Question:

 How can I conditionally compile Metacommands? Metacommands require the
 "$" in the first column of the source line, and the /4cc switch also
 requires a character in the first column.

 Response:

 You cannot use the /4cc switch to conditionally compile metacommands.
 The metacommands $IF, $ELSE, $ELSEIF, and $ENDIF, as well as $DEFINE
 and /D, are designed for the conditional compiling of metacommands.
 Pages 281-284 and 335 of the "Microsoft FORTRAN Reference" manual for
 Version 5.00 cover the use of these commands.

 The following example demonstrates how to conditionally compile using
 these commands:

 $IF DEFINED (L)
 $INCLUDE 'large.inc'
 $ELSE
 $INCLUDE 'medium.inc'
 $ENDIF

 If the source file does not contain the line "$DEFINE L" preceding
 this $IF block, the $ELSE half is compiled and the file MEDIUM.INC is
 included. If "$DEFINE L" precedes this $IF block, the file LARGE.INC
 is included; this gives you the ability to hard code the conditional
 changes.

 If you'd like to change the compilation without hard coding it, the /D
 option on the command line allows you to define the variable that is
 used with the $IF block. This action eliminates the need for the
 $DEFINE metacommand. In the previous example, if you wanted to include
 the file LARGE.INC, you'd compile with a line such as the following:

    fl /DL name.ext


 516. FORTRAN Err Msg F3606, F3607: Type and Length Mismatch

 Product Version(s): 4.00 4.01 4.10 5.00 | 4.10 5.00
 Operating System:   MS-DOS              | OS/2
 Flags: ENDUSER |
 Last Modified:  6-DEC-1989    ArticleIdent: Q49467

 When calling a subroutine or function on a VAX with FORTRAN Versions
 4.x or 5.00, you don't need to be consistent when passing formal
 arguments. When porting VAX code down to a PC, the FORTRAN 5.00
 compiler catches this inconsistency with the errors F3606 (type
 mismatch) and F3607 (length mismatch).

 F3606 and F3607 are recoverable errors; the compiler produces an OBJ
 file. You can either ignore the errors or be consistent when passing
 formal arguments.

 For more information, see Page 462 in the "Microsoft FORTRAN
 Reference" manual for Version 5.00.

 The following code generates the errors:

       integer*4 intX
       logical*1 logic
       call sub1(logic)
       call sub1(intX)
       end
 c
       subroutine sub1 (intY)
       integer*4 intY
       end

 When the compiler interprets this code, it reserves 4 bytes for the
 intX variable and 1 byte for logic. It then finds the "call
 sub1(logic)" line and assumes the formal argument needs only 1 byte.
 When it comes across the next call to sub1, the compiler finds the
 formal argument has changed and flags the errors. Not only has the
 length of the formal argument changed, the type has also changed.


 517. Using FORTRAN to Check Syntax, /Zi and /Fs

 Product Version(s): 4.00 4.01 4.10 5.00 |4.00 4.01 4.10 5.00
 Operating System:   MS-DOS              | OS/2
 Flags: ENDUSER |
 Last Modified:  6-DEC-1989    ArticleIdent: Q49493

 If you compile with /Zs using FORTRAN Versions 4.x or 5.00, the
 FORTRAN compiler checks only the syntax of the source file.

 Using /Zs eliminates the bulk of the compiler's work, thus saving time
 during compilation. Using /Fs in conjunction with /Zs prompts the
 compiler to record the error messages to a file.

 The /Zs option should be used for the first few compilations. After
 the majority of the syntax errors are corrected, compile without /Zs.


 518. END DO Example Incorrect in FORTRAN 5.00 Reference Manual

 Product Version(s): 5.00   | 5.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | docerr
 Last Modified:  6-DEC-1989    ArticleIdent: Q49496

 If you compile the example on Page 159 of the "Microsoft FORTRAN
 Reference" manual for Version 5.00, an F2115 syntax error occurs.

 This error occurs because the second print statement incorrectly
 contains a comma.

 The example from page 159 follows:

       Do ivar = 1, 10
          PRINT ivar
       END DO

       ivar = 0
       DO WHILE (ivar .LT. 10)
          ivar = ivar + 1
          Print , ivar     ! delete the comma in this line
       END DO


 519. FORTRAN Err Msg: D2027: Could Not Execute 'Filename'

 Product Version(s): 5.00   | 5.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified:  6-DEC-1989    ArticleIdent: Q49497

 When invoking the FORTRAN compiler, I get the following error:

    D2027: could not execute F1.EXE

 This error very likely occurs because the system doesn't have enough
 memory to load the file F1.EXE (the first pass of the compiler).
 FORTRAN requires 320K of free memory to load (512K is recommended).

 To work around this problem, try to eliminate other programs [e.g.
 terminate-and-stay-resident programs (TSRs)] from memory, thereby
 making that memory available for FORTRAN.

 The "Microsoft FORTRAN Reference" manual for Version 5.00 states the
 following on Page 411:

    The specified file containing a compiler pass or the linker was
    found but for some reason could not be executed. An illegal EXE
    file format is the most likely cause.


 520. FORTRAN Err Msg: QuickBASIC Calling FORTRAN Error F6700

 Product Version(s): 4.10 5.00
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified:  6-DEC-1989    ArticleIdent: Q49498

 Question:

 When I compile and link a QuickBASIC program calling a FORTRAN
 subroutine, I get the following error message:

    F6700: Heap Space Limit Exceeded error

 Response:

 This error occurs because QuickBASIC needs to define a stack that
 FORTRAN can use, as demonstrated by the following code:

 QuickBASIC Code
 ---------------

     DIM heap%(2048)
     COMMON SHARED /nmalloc/ heap%()

     REM ** TO DECLARE 2K OF HEAP SPACE THE FORTRAN
     REM ** CAN USE

     DECLARE SUB ftest ALIAS "ftest"
     CALL ftest
     PRINT ""
     PRINT "Return from Fortran subroutine"
     END

 FORTRAN Code
 ------------

     SUBROUTINE ftest
     WRITE (*,*) 'Into the Fortran subroutine'
     RETURN
     END

 The QuickBASIC code must be compiled as stand-alone code. To compile
 and link, do the following:

 BC /o basic.bas

 FL /c fortran.for

 LINK /NOE basic+fortran,,,bcom45 llibfore;

    (Where basic.bas is the basic source code and fortran.for
    is the fortran source code.)

    You should link with the QuickBasic BCOM45 library first
    and specify which Fortran library to use (LLIBFOR7,
    LLIBFORE,...)


 521. Ways to Open a File from the Command Line in FORTRAN

 Product Version(s): 4.00 4.10 5.00 | 4.00 4.10 5.00
 Operating System:   MS-DOS         | OS/2
 Flags: ENDUSER |
 Last Modified:  6-DEC-1989    ArticleIdent: Q49507

 FORTRAN allows the following three different ways to open files:

 1. Hard coding the filename.

 2. Allowing the user to enter the filename.

 3. Letting the program create a temporary file.

 All of these options are covered on Pages 203-204 of the "Microsoft
 FORTRAN Reference" manual for Version 5.00 and Page 249 of the
 "Microsoft FORTRAN Optimizing Compiler: Language Reference" for
 Versions 4.x.

 To open a file from the command line, you must do the following:

 1. Set the FILE parameter in the OPEN statement equal to a blank
    (FILE=' ').

 2. Specify the full filename of the file to be opened on the command
    line when activating the program.

 Consider the following code as an example. The source file is called
 "test.for" and appears as follows:

       PROGRAM test
       OPEN (10,FILE=' ')
       END

 The data file to be opened is called "test.dat". To open the file from
 the command line, type the following:

       test test.dat

 If you fail to specify the data filename on the command line, the
 program prompts you for the file to be opened.


 522. FORTRAN Err Msg: F1050: Code Segment Too Large (4718)

 Product Version(s): 3.30 3.31 4.00 4.01 4.10 5.00 | 4.10 5.00
 Operating System:   MS-DOS                        | OS/2
 Flags: ENDUSER | VAX port
 Last Modified:  6-DEC-1989    ArticleIdent: Q49515

 When I download a FORTRAN source code that contains 5878 lines of code
 from the Prime Mini-Computer and the entire source is contained within
 one module, the following error is generated during compilation:

    F1050: CODE SEGMENT TOO LARGE (4718)

 The amount of code within the one module exceeds 64K in size, so you
 need to modularize this program source code. Break the code into
 subroutines and place some of these subroutines into another file.
 This procedure results in several .FOR files, which can be compiled
 separately and then linked together to form one .EXE file.

 The limitation on the size of a code segment also applies to OS/2
 because OS/2 is based upon the segmented architecture of the 80286.


 523. L2029: Unresolved External _main in crt0.asm

 Product Version(s): 4.10 5.00 | 4.10 5.00
 Operating System:   MS-DOS    | OS/2
 Flags: ENDUSER | L2029 F2830
 Last Modified:  6-DEC-1989    ArticleIdent: Q49526

 UNRESOLVED EXTERNALS referencing "crt0.asm in _main", "end not found"
 or ENTGQQ can occur because the compiler or linker cannot determine an
 entry point into the program.

 To correct this problem, make sure that the FORTRAN source code begins
 in column seven and that the program has an END statement.

 Each line of the following program starts in column one. The compiler
 views these lines as comments, and does not flag an error. However, at
 link time, the LINKer cannot find the end statement, and therefore
 cannot identify the main program. Thus, the unresolved external
 _main occurs.

 integer*4 i
 i=5
 write(*,*) i
 end

 ... crt0.asm) : error L2029 : '_main' : unresolved external

 If the same code is moved to column seven, but the end statement is
 removed, the following compiler error occurs:

    error F2830: END missing


 524. Writing Nonprintable Characters with FORTRAN

 Product Version(s): 4.00 4.01 4.10 5.00 | 4.00 4.01 4.10 5.00
 Operating System:   MS-DOS              | OS/2
 Flags: ENDUSER | ascii ctrl-z escape esc lf linefeed
 Last Modified:  6-DEC-1989    ArticleIdent: Q49528

 If you need to print a nonprintable character with FORTRAN, you can
 use the CHAR intrinsic function. The CHAR intrinsic function accepts
 an integer and converts it to a character. The following code
 demonstrates this idea:

       write (*,'(A1)') CHAR(13)

 This line of code writes the nonprintable character, carriage return,
 to the screen.


 525. FORTRAN Err Msg D2027 When Compiling with FORTRAN, M Editor

 Product Version(s): 5.00
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified:  6-DEC-1989    ArticleIdent: Q49534

 Problem:

 I tried to compile FORTRAN Version 5.00 source code while using the M
 Editor Version 1.02. M issued a beep almost instantly, and did not
 display any error messages.

 Examination of the M.MSG file located in the TMP directory revealed
 the following error message:

    Command line error D2027 : could not execute 'C:\BIN\f1.exe'

 Prior to entering the editor, a CHKDSK revealed 445,000 bytes of
 available RAM.

 Response:

 This error message occurs because of the lack of available memory to
 run the entire FORTRAN compilation process. If you want to compile
 from within the Editor, you need at least 480K free before invoking M,
 depending on the size of the source code. Larger programs consequently
 require more free memory.


 526. Conditional Compiling with $DEBUG

 Product Version(s): 4.00 4.01 4.10 5.00 | 4.00 4.01 4.10 5.00
 Operating System:   MS-DOS              | OS/2
 Flags: ENDUSER |
 Last Modified:  6-DEC-1989    ArticleIdent: Q49670

 Page 286 of the "Microsoft FORTRAN Reference" manual for Version 5.00
 and Page 289 of the Microsoft FORTRAN Optimizing Compiler: Language
 Reference" for Versions 4.00 and 4.10 state that the $DEBUG
 metacommand can be used for conditional compilation. The example
 below demonstrates this.

 In the following code fragment, only the lines that start with either
 the letter "A" or "B" are compiled; the other lines are considered
 comments:

 $DEBUG:'AB'
 A     integer*2 N
 B     integer*2 M
 C     integer*4 N
 D     integer*4 M
 A     real*4 R
 C     real*8 R
 C

 The last paragraph on Page 286 of the "Microsoft FORTRAN Reference"
 for Version 5.00 states the following:

      If the optional string is specified, the characters
      in string specify that lines with those characters in
      column 1 are to be compiled into the program. Case is
      not significant. Note that the letter C always
      indicates a comment line; therefore, if string contains
      a C, the C is ignored.

 Page 290 of the "Microsoft FORTRAN Optimizing Compiler: Language
 Reference" for Versions 4.00 and 4.10 has a similar paragraph.

 For more information on conditional compiling, see the /4cc compile
 option on Page 335 of the FORTRAN 5.00 reference manual and Page 93 of
 the FORTRAN 4.00/4.10 user's guide mentioned above.


 527. FORTRAN Err Msg: F1901: Program Too Large for Memory

 Product Version(s): 5.00   | 5.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified:  6-DEC-1989    ArticleIdent: Q49708

 If a program uses a DATA statement that contains an extensive amount
 of data, the compiler may generate the following fatal error:

    F1901: program too large for memory

 The FORTRAN compiler uses the near heap to store data during
 compilation. This space can be exceeded. To free up near heap memory,
 use the high capacity compiler, which became available with FORTRAN
 Version 5.00.

 To use the high capacity compiler, copy the file F1L.EXE from the
 FORTRAN 5.00 High Capacity Compiler Disk to the FORTRAN BIN directory
 and compile with the /B1 switch.

 For example, if the source file is TEST.FOR and the high capacity
 Compiler is in the C:\FORTRAN\bin directory, compile using the
 following line:

 FL /B1 C:\FORTRAN\BIN\F1L.EXE TEST.FOR

 The following source code demonstrates this problem. If the array
 subscript for tmp changes from 254 to 256, or if another data item is
 added to the file, the program is too large for memory. The problem is
 corrected by using the high capacity compiler.

       subroutine test ()
       real tmp(254) ! low cc limit 254
       DATA tmp / 0.0, .035, .049, .049, 0.0, 0.0, .068, .068, 0.0,
      Z            .095, .095, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, .049,
      Z            .065, .065, 0.0, 0.0, .088, .088, 0.0, .119, .119,
      Z            0.0, 0.0, 0.0, 0.0, 0.0, 0.0, .049, .065, .065,
      Z            0.0, 0.0, .091, .091, 0.0, .126, .126, 0.0, 0.0,
      Z            0.0, 0.0, 0.0, .065, .065, .083, .083, 0.0, 0.0,
      Z            .109, .109, 0.0, .147, .147, 0.0, 0.0, 0.0, .187,
      Z            .294, .065, .065, .083, .083, 0.0, 0.0, .113, .113,
      Z            0.0, .154, .154, 0.0, 0.0, 0.0, .218, .308, .065,
      Z            .065, .109, .109, 0.0, 0.0, .133, .133, 0.0, .179,
      Z            .179, 0.0, 0.0, 0.0, .250, .358, .065, .065, .109,
      Z            .109, 0.0, 0.0, .140, .140, 0.0, .191, .191, 0.0,
      Z            0.0, 0.0, .250, .382, .065, .065, .109, .109, 0.0,
      Z            .095, .095, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, .049,
      Z            .065, .065, 0.0, 0.0, .088, .088, 0.0, .119, .119,
      Z            0.0, 0.0, 0.0, 0.0, 0.0, 0.0, .049, .065, .065,
      Z            0.0, 0.0, .091, .091, 0.0, .126, .126, 0.0, 0.0,
      Z            0.0, 0.0, 0.0, .065, .065, .083, .083, 0.0, 0.0,
      Z            .109, .109, 0.0, .147, .147, 0.0, 0.0, 0.0, .187,
      Z            .294, .065, .065, .083, .083, 0.0, 0.0, .113, .113,
      Z            0.0, .154, .154, 0.0, 0.0, 0.0, .218, .308, .065,
      Z            .065, .109, .109, 0.0, 0.0, .133, .133, 0.0, .179,
      Z            .179, 0.0, 0.0, 0.0, .250, .358, .065, .065, .109,
      Z            .109, 0.0, 0.0, .140, .140, 0.0, .191, .191, 0.0,
      Z            0.0, 0.0, .250, .382, .065, .065, .109, .109, 0.0,
      Z            .095, .095, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, .049,
      Z            0.0, 0.0, .091, .091, 0.0, .126, .126, 0.0, 0.0,
      Z            0.0, 0.0, 0.0, .065, .065, .083, .083, 0.0, 0.0,
      Z            .109, .109, 0.0, .147, .147, 0.0, 0.0, 0.0, .187,
      Z            .294, .065, .065, .083, .083, 0.0, 0.0, .113, .113,
      Z            0.0, .154, .154, 0.0, 0.0, 0.0, .218, .308, .065,
      Z            .065, .109, .109, 0.0, 0.0, .133, .133, 0.0, .179,
      Z            .179, 0.0, 0.0, 0.0, .250, .358, .065, .065, .109,
      Z            .109, 0.0, 0.0, .140, .140, 0.0, .191, .191, 0.0,
      Z            0.0, 0.0, .250, .382, .065, .065, .109, .109, 0.0,
      Z            .095, .095, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, .049,
      Z            .065, .065, 0.0, 0.0, .088, .088, 0.0, .119, .119,
      Z            0.0, 0.0, 0.0, 0.0, 0.0, 0.0, .049, .065, .065,
      Z            0.0, 0.0, .091, .091, 0.0, .126, .126, 0.0, 0.0,
      Z            0.0, 0.0, 0.0, .065, .065, .083, .083, 0.0, 0.0,
      Z            .109, .109, 0.0, .147, .147, 0.0, 0.0, 0.0, .187,
      Z            .294, .065, .065, .083, .083, 0.0, 0.0, .113, .113,
      Z            0.0, .154, .154, 0.0, 0.0, 0.0, .218, .308, .065,
      Z            .065, .109, .109, 0.0, 0.0, .133, .133, 0.0, .179,
      Z            .179, 0.0, 0.0, 0.0, .250, .358, .065, .065, .109,
      Z            .109, 0.0, 0.0, .140, .140, 0.0, .191, .191, 0.0,
      Z            0.0, 0.0, .250, .382, .065, .065, .109, .109, 0.0,
      Z            .095, .095, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, .049,
      Z            .065, .065, 0.0, 0.0, .088, .088, 0.0, .119, .119,
      Z            0.0, 0.0, 0.0, 0.0, 0.0, 0.0, .049, .065, .065,
      Z            0.0, 0.0, .091, .091, 0.0, .126, .126, 0.0, 0.0,
      Z            0.0, 0.0, 0.0, .065, .065, .083, .083, 0.0, 0.0,
      Z            .109, .109, 0.0, .147, .147, 0.0, 0.0, 0.0, .187,
      Z            .294, .065, .065, .083, .083, 0.0, 0.0, .113, .113,
      Z            0.0, .154, .154, 0.0, 0.0, 0.0, .218, .308, .065,
      Z            .065, .109, .109, 0.0, 0.0, .133, .133, 0.0, .179,
      Z            .179, 0.0, 0.0, 0.0, .250, .358, .065, .065, .109,
      Z            .109, 0.0, 0.0, .140, .140, 0.0, .191, .191, 0.0,
      Z            0.0, 0.0, .250, .382, .065, .065, .109, .109, 0.0,
      Z            0.0, .145, .145, 0.0, .200, .200, 0.0, 0.0, 0.0, .281/
       write (*,*) tmp
       end


 528. Optimizing Logical IF Statements with FORTRAN

 Product Version(s): 4.00 4.10 5.00 | 4.10 5.00
 Operating System:   MS-DOS         | OS/2
 Flags: ENDUSER | label run run-time buglist5.00
 Last Modified: 16-JUL-1990    ArticleIdent: Q49731

 FORTRAN may not correctly optimize some logical IF statements inside
 GOTO loops. The result is execution of a different branch of code than
 expected. Try compiling without optimization (/Od).

 If optimization is required, one solution is to change a logical IF
 statement to a standard IF statement. The following is an example:

        if (j .GE. 3) GOTO 3100    ! logical IF statement

 Change to the following:

        if (j .GE. 3) then         ! standard IF statement
          GOTO 3100
        endif

 When the compiler encounters the logical IF and GOTO loop, as shown in
 the code shown below, it compiles and runs without errors, but the
 correct lines are not executed.

 When the code is optimized, the GOTO 3100 statement in the logical IF
 is ignored and the program prints "at 3200, loop failed".

 When the same file is compiled without optimization, the logical if
 statement works correctly and the program prints "at 3100, loop
 worked".

 Sample Code
 -----------

       j=0
 3190  continue
       if (j .ge. 3) Goto 3100       ! The logical IF
       j=j+1
       Goto 3190                     ! The Goto loop
 3200  continue
       write (*,*) 'at 3200, loop failed'
       stop
 3100  continue
       write (*,*) 'at 3100, loop worked'
       stop
       end


 529. Compiler Error in p2symtab.c at Line 939 in FORTRAN 5.00

 Product Version(s): 5.00   | 5.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | buglist5.00
 Last Modified:  6-DEC-1989    ArticleIdent: Q49761

 The following error occurs when a variable is initialized in a type
 statement and then accessed with a COMMON or EQUIVALENCE statement.
 An F2311: 'COMMON or EQUIVALENCE preinitialization illegal' should be
 generated instead.

 The variable should be initialized within the body of the program
 rather than with the type statement if COMMON or EQUIVALENCE is to be
 used.

 fatal error F1001: Internal Compiler Error
               (compiler file '@(#)p2symtab.c:1.4', line 939)
               Contact Microsoft Technical Support

 Remove the /100/ from the following line, and the code compiles
 properly:

       integer*4 i/100/      !preinitialization illegal
       integer*4 j

       common /dow/i
 C     equivalence(i,j)
       i=100            !initialize the variable here instead
       j=3
       end

 The code should generate the following error:

    error F2311: I : COMMON (or EQUIVALENCE or STRUCTURE):
    preinitialization illegal

 Page 135 of the "Microsoft FORTRAN Reference" manual for Version 5.00
 states that the following example causes a compile-time error:

       INTEGER i /1/
       COMMON i

 Page 165 of the same manual includes a similar statement about the
 EQUIVALENCE statement:

       INTEGER i /1/
       EQUIVALENCE (i, j)


 530. Increasing Units Documentation Error in FORTRAN Reference

 Product Version(s): 5.00   | 5.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | docerr
 Last Modified:  6-DEC-1989    ArticleIdent: Q49894

 The information on Page 405, Section C.3.1.2, "Increasing Units," in
 the "Microsoft FORTRAN Reference" manual for Version 5.00 incorrectly
 states the following:

    ...so that the number in the line

       _NFILE_ = 20

    equals the same value...

 The correct information should be as follows:

    ...so that the numbers in the lines

          _NFILE_  equ 20
       else
          _NFILE_  equ 40
       endif

    both equal the value...


 531. F6405, End-of-File and the BACKSPACE Command

 Product Version(s): 4.00 4.01 4.10 5.00 | 4.10 5.00
 Operating System:   MS-DOS              | OS/2
 Flags: ENDUSER | buglist5.00
 Last Modified: 25-FEB-1991    ArticleIdent: Q49896

 The BACKSPACE command may not work correctly if used in conjunction
 with the END parameter in a READ statement. To solve this problem, use
 the EOF intrinsic function.

 One situation that demonstrates this problem is when reading through a
 file with the lines

 50    read(10,20,err=30,end=40) variable
       goto 50

 and you try to BACKSPACE command after encountering the end-of-file
 character. The BACKSPACE command will not work in this situation, and
 F6405 "external I/O illegal beyond end of file" will be generated
 because no BACKSPACING has occurred.

 To work around this problem, use the EOF intrinsic function instead of
 the END parameter. Try reading the file with the following code
 instead:

       do while ( .not. EOF(10))
         read(10,20,err=30) variable
       end do

 Microsoft has confirmed this to be a problem in FORTRAN Version 5.00.
 We are researching this problem and will post new information as it
 becomes available.


 532. The SYSTEM Function Won't Execute SET string=string

 Product Version(s): 4.10 5.00 | 4.10 5.00
 Operating System:   MS-DOS    | OS/2
 Flags: ENDUSER |
 Last Modified:  6-DEC-1989    ArticleIdent: Q49921

 The SYSTEM function included with the FORTRAN library will not execute
 the DOS command SET string=string. This limitation preserves the
 environment of the calling program, preventing it from being corrupted
 by the SYSTEM call.

 The following code will compile and run, and the line SET CL=/FPi /Lr
 appears on the screen, but the environment is not altered to set CL:

       INTERFACE TO FUNCTION SYSTEM[C] (STRING)
       INTEGER*2 SYSTEM
       CHARACTER*1 STRING[REFERENCE]
       END

       INTEGER*2 SYSTEM
       I=SYSTEM('SET CL=/FPi /Lr'C)
       END


 533. General Differences between /FPi, /FPc, /FPa Compile Options

 Product Version(s): 4.00 4.01 4.10 5.00 | 4.00 4.01 4.10 5.00
 Operating System:   MS-DOS              | OS/2
 Flags: ENDUSER |
 Last Modified:  7-DEC-1989    ArticleIdent: Q50320

 The compile options /FPi, /FPc, and /FPa instruct the FORTRAN compiler
 to generate an executable program in different ways.

 The /FPi option generates in-line instructions for a math coprocessor
 and places the name of the emulator library in the object file. If a
 math coprocessor is present at run time, the program uses the
 coprocessor, If it's not available, it simulates the coprocessor. The
 object file must be linked with the emulator library.

 The /FPc option generates floating-point calls to the emulator library
 and allows linking with either the 8087/287/387, alternate, or
 emulator libraries.

 The /FPa option generates floating-point calls and places
 the name of the alternate library in the object file.

 The above information is found in Chapter 1 of the "Microsoft FORTRAN
 Advanced Topics" manual for FORTRAN 5.0 and Chapter 8 of the FORTRAN
 4.X User's Guide.


 534. Precision of Reals with FORTRAN

 Product Version(s): 4.00 4.01 4.10 5.00 | 4.00 4.01 4.10 5.00
 Operating System:   MS-DOS              | OS/2
 Flags: ENDUSER |
 Last Modified:  7-DEC-1989    ArticleIdent: Q50325

 When using Microsoft FORTRAN, the precision of a REAL*4 variable is
 six or seven decimal places. The precision of a REAL*8 is fifteen or
 sixteen places.

 The "Microsoft FORTRAN Reference" manual for Version 5.00 covers
 single- and double-precision IEEE real data types on Pages 12 and 13.
 (For Versions 4.00, 4.01, and 4.10, please see Pages 22, 23, and 24 of
 the "Microsoft FORTRAN Optimizing Compiler: Language Reference."


 535. Spawnlp and Overlaying the Parent Process

 Product Version(s): 5.00
 Operating System:   MS-DOS
 Flags: ENDUSER | S_C S_QuickC
 Last Modified:  7-DEC-1989    ArticleIdent: Q50331

 While the Spawnlp function included with FORTRAN Version 5.00 supports
 the option of suspending the parent process, it does not support the
 option of overlaying (terminating) the parent process. This
 information is documented on Page 87 of the "Microsoft FORTRAN
 Advanced Topics" manual for Version 5.00.

 To overlay the parent process, write a dummy C routine that calls the
 Spawnlp function with the P_OVERLAY parameter. See the C documentation
 for more information about Spawnlp and P_OVERLAY.

 The sample code below illustrates the process that terminates the
 parent so the second message is not printed:

 The following is the FORTRAN parent process:

       INTERFACE TO SUBROUTINE SPC [C]
       END

       WRITE(*,*) 'I AM A PARENT. I AM ALIVE.'
       CALL SPC
       WRITE(*,*) 'PARENT STILL ALIVE'   !not printed
       END

 The following is a dummy C routine (this routine has been successfully
 tested with C 5.10 and QuickC 2.01):

  #include <process.h>
  #include <stdio.h>
  spc()
  {
   spawnlp (P_OVERLAY,"FORM.EXE","FORM.EXE",NULL);
  }

  File FORM.FOR:

       WRITE (*,*) 'HI THERE ! I AM A CHILD PROCESS...'
       END

 The following is the program output:

 I AM A PARENT. I AM ALIVE.HI THERE ! I AM A CHILD PROCESS...

 Make sure that you compile FORTRAN and C routines using the same
 memory model (FORTRAN and C have different defaults). When linking C
 and FORTRAN modules, use the /NOE switch and list the FORTRAN 5.00
 library first.


 536. FORTRAN Reserved File Names

 Product Version(s): 5.00   | 5.00
 Operating System:   MS-DOS | OS/2
 Flags: PSSONLY | ENDUSER
 Last Modified: 30-OCT-1990    ArticleIdent: Q50332

 The following is a list of reserved file names in Microsoft FORTRAN.
 This information is from the FORTRAN 5.0 README.DOC.

    Reserved word     Description
    -------------     -----------

    CON               Keyboard and screen
    USER              Keyboard and screen
    PRN               Printer (LPT1)
    COM1              Communications port 1
    LPT1              Printer
    NUL               Null device
    AUX               Communications port (COM1)
    ERR               Standard error output (screen)
    LINE              Communications port (COM1)

 You can use READ, WRITE, and OPEN statements (as appropriate) to
 access these devices, and CLOSE statements to disconnect them, just as
 you would with other files. FORTRAN carriage-control characters are
 recognized for these devices.

 Problems can occur if you use these reserved words incorrectly (e.g.
 if you try to use one as a regular disk filename). For example, if you
 open a file called LINE.DOC, reading from that file can cause your
 computer to lock unless there is an active data transmitting device
 connected to COM1.


 537. Parameter Syntax Not Correctly Interpreted

 Product Version(s): 5.00   | 5.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | buglist5.00
 Last Modified:  6-DEC-1989    ArticleIdent: Q49976

 Microsoft FORTRAN Version 5.00 does not correctly interpret the syntax
 of the parameter statement. If the parentheses are left off, either
 the compiler does not generate an error or, if there are any
 statements that follow the parameter statement, the compiler generates
 the error "F2836: statement out of order."

 The compiler does not catch the syntax error in the following program.
 The parameter statement should be "parameter (n=1)":

       integer*2 n
       parameter n=1
       end

 The compiler incorrectly generates the error F2836 when compiling the
 following code, not because the third line is out of order, but
 because of the improper syntax in the parameter statement:

       integer*2 n
       parameter n=1
       integer*2 m
       end


 538. EXEPACK.EXE Not Included with FORTRAN 5.00; Use Link /E

 Product Version(s): 5.00   | 5.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | exepack
 Last Modified: 31-OCT-1989    ArticleIdent: Q50053

 The EXEPACK Utility is not included with FORTRAN Version 5.00. To pack
 an object file, use the linker /E switch.

 The above information is documented in the FORTRAN 5.0 README.DOC.
 A description of the /E switch is located on page 241 of the FORTRAN
 5.0 CodeView and Utilities User's Guide.


 539. Concatenation with /Gr switch Works Incorrectly

 Product Version(s): 4.00 4.01 4.10 | 4.10
 Operating System:   MS-DOS         | OS/2
 Flags: ENDUSER |
 Last Modified:  7-DEC-1989    ArticleIdent: Q50573

 When using the /Gr switch to enable FORTRAN code compiled with a
 FORTRAN compiler Version 4.x to be compatible with the code from
 FORTRAN Version 3.20, the character concatenation operator does not
 function correctly with variables.

 When attempting to concatenate two character strings using the
 following format

 j=4
 foo='test'
 foo2=foo(1:j)//'.one'

 the concatenation operation is ignored and foo2 equals 'test' if the
 /Gr switch, which enables backward compatibility to FORTRAN Version
 3.20, is used.

 When an explicit value is used in place of the variable "j", the
 concatenation operation is successful, as shown in the following
 example:

 foo='test'
 foo2='foo(1:4)//'.one'

 In this case, foo2 equals 'test.one'.


 540. FORTRAN Index Listing for Binary Records Incorrect

 Product Version(s): 5.00   | 5.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | docerr
 Last Modified:  7-DEC-1989    ArticleIdent: Q50574

 The index of the "Microsoft FORTRAN Advanced Topics" manual for
 Version 5.00 incorrectly states that information on binary records is
 on Pages 119-120.

 The information actually appears on Pages 122-124.


 541. "Issuing Fixup Warnings" Section Is 13.3.32 in FORTRAN Manual

 Product Version(s): 5.00   | 5.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | /WARNFIXUP docerr
 Last Modified:  7-DEC-1989    ArticleIdent: Q50575

 Under the Link warning message L4000 on Page 386 in the "Microsoft
 FORTRAN CodeView and Utilities User's Guide" for Version 5.00, the
 documentation incorrectly states that Section 13.3.31 is the "Issuing
 Fixup Warnings" section.

 The "Issuing Fixup Warnings" section actually is 13.3.32.


 542. \s Format Switch Information in MS-DOS, Not FORTRAN, Manual

 Product Version(s): 5.00   | 5.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | docerr
 Last Modified:  7-DEC-1989    ArticleIdent: Q50576

 On Page 16 of the "Microsoft FORTRAN Advanced Topics" manual for
 Version 5.00, the first step suggests formatting a blank floppy disk
 without the /s option. It then incorrectly states that more
 information is available on the /s switch in the "Microsoft FORTRAN
 Reference" manual.

 For more information on the /s switch, you should consult an MS-DOS
 manual.


 543. Example of Using EXTERNAL for User-Defined Function

 Product Version(s): 5.00   | 5.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified:  7-DEC-1989    ArticleIdent: Q50401

 The following is an example of how to use the EXTERNAL command in
 FORTRAN Version 5.00 to specify a user-defined function:

       function fn (x)
         real fn,x
         fn=x
       end

       subroutine s2 (f,x,y)
         real   f,x,y
         x=f(y)
       end

 The following is the main program:

       real      y,z,fn
         external  fn
         z=10.0
         call s2(fn,y,z)
         write (*,*) y
       end


 544. Compiling with /ND Option Causes Hang at Run Time

 Product Version(s): 4.10 5.00 | 4.10 5.00
 Operating System:   MS-DOS    | OS/2
 Flags: ENDUSER |
 Last Modified: 19-JUL-1990    ArticleIdent: Q50402

 Compiling the program below with /ND and FORTRAN Version 4.10 generates
 an internal compiler error and using /ND with FORTRAN 5.00 hangs the
 machine at run time.  No errors occur when the WRITE statement is
 removed.

 The /ND switch is used to name the data segment.

 The following code demonstrates both situations when compiled with the
 /ND switch.  No errors occur when the module does not perform I/O
 operations.

       integer*2 n
       n=1
       write (*,*) n
       end

 Microsoft is researching this problem and will post new information
 here as it becomes available.


 545. Using an Internal Write and outtext/outgtext for Numeric Data

 Product Version(s): 5.00   | 5.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | internal files
 Last Modified:  9-MAY-1990    ArticleIdent: Q61524

 Below is an example of an internal write to a character variable. This
 is useful when outputting numerical data in a graphics mode by using
 the functions outtext or outgtext.

 C Example of an internal write in FORTRAN
 C
       include 'fgraph.fi'
       include 'fgraph.fd'
       integer*4 var1
       character*15 output
       var1 = 1234
       write (output,100) var1 ! write var1 to output variable
       call outtext(output)    ! use outtext to write output to screen
 100   format ('VAR1 = ', I4)
       end

 The above code shows how an internal write can be used to write
 numerical data (formatted or unformatted) to a character string. The
 character string variable name is given as the unitspec for the WRITE
 statement. The formatspec and iolist are used normally. After the
 WRITE statement is executed the character string output contains the
 ASCII characters listed below in single quotation marks:

    output = 'VAR1 = 1234    '

 The graphics functions outtext and outgtext will only output character
 strings to the screen. This poses a problem when outputting integer
 and real values. An internal write will solve the problem.

 Internal files are explained on Pages 77-78 of the "Microsoft FORTRAN
 Reference" manual. Using the WRITE statement with internal files is
 explained on Pages 234-235 of the "Microsoft FORTRAN Reference"
 manual. Outtext and outgtext are explained on Pages 231-232 of the
 "Microsoft FORTRAN Advanced Topics" manual.


 546. Enabling/Disabling FORTRAN SAA, VAX Extensions

 Product Version(s): 5.00   | 5.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified:  7-DEC-1989    ArticleIdent: Q50480

 The /4Ys, /4Yi, and /4Yv compiler switches control the use of
 Microsoft's non-ANSI standard (FORTRAN 77) options:

    Switch     Description
    ------     -----------

    /4Ys       Disables the use of all Microsoft FORTRAN extensions

    /4Yi       Disables all extensions except the IBM SAA extensions

    /4Yv       Disables all but the VAX extensions

 The following contains lists of supported IBM SAA and VAX extensions.
 Most of the information in these lists is located on Pages 330-332 of
 the "Microsoft FORTRAN Reference" manual for Version 5.00. See
 Appendix B in this reference manual for additional features new to
 FORTRAN 5.00.

 Microsoft FORTRAN includes all SAA extensions that are listed below:

  1. 31 character names

  2. Bit manipulation intrinsic

  3. Case insensitive source

  4. COMMON that allows character and noncharacter in same block

  5. CONJG, HFIX, IMAG intrinsic functions

  6. Data initialization in type statements

  7. EQUIVALENCE allows association of character and noncharacter

  8. Functions IOR, IAND, NOT IEOR, ISHFT, BTEST, IBSET, and IBCLR

  9. IMPLICIT NONE

 10. INCLUDE compiler directive

 11. INTEGER*2, COMPLEX*16, and LOGICAL*1 data types

 12. Optional length specifications in INTEGER, REAL, COMPLEX, and
     LOGICAL type statements

 13. Use of underscore (_) in names

 14. Z edit descriptor

 Microsoft FORTRAN also includes many, but not all, VAX extension as
 listed below:

  1. 31 character names

  2. ACCESS selector 'APPEND' in the OPEN statement

  3. Allowing integer arrays to contain FORMAT statements

  4. BLOCKSIZE and NML I/O keywords

  5. Debug comment lines

  6. DO statements without specified labels

  7. DO WHILE statement

  8. END DO statement

  9. EQUIVALENCE of character and noncharacter items

 10. EQUIVALENCE to a multi-dimensional array with only one subscript

 11. Exponentiation of REAL and COMPLEX statements

 12. IMPLICIT NONE

 13. INCLUDE compiler directive

 14. Initialization on the declaration line

 15. In-line comments

 16. Length specification within the FUNCTION statement

 17. Length specifications within type declarations

 18. Mixing of character and noncharacter items in COMMON statements

 19. NAMELIST

 20. Noninteger alternate return values

 21. Noninteger array subscripts

 22. Numeric operands for .AND., .OR., etc.

 23. Specified common-block variables in DATA statements outside a
     BLOCK DATA subroutine

 24. STRUCTURE, UNION, MAP statements

 25. Up to 99 continuation lines

 26. Use of dollar sign ($) in names

 27. .XOR. operator


 547. VAX Extensions Available with FORTRAN 5.00

 Product Version(s): 5.00   | 5.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified:  7-DEC-1989    ArticleIdent: Q50504

 Microsoft FORTRAN includes many, but not all, VAX extensions. Most of
 these extensions are found on Pages  331-332 of the "Microsoft FORTRAN
 Reference" manual for Version 5.00. Appendix B of the same manual
 lists additional features that are new in FORTRAN 5.00.

 The supported VAX extensions are listed below:

  1. 31 character names

  2. ACCESS selector 'APPEND' in the OPEN statement

  3. Allowing integer arrays to contain FORMAT statements

  4. BLOCKSIZE and NML I/O keywords

  5. Debug comment lines

  6. DO statements without specified labels

  7. DO WHILE statement

  8. END DO statement

  9. EQUIVALENCE of character and noncharacter items

 10. EQUIVALENCE to a multi-dimensional array with only one subscript

 11. Exponentiation of REAL and COMPLEX statements

 12. IMPLICIT NONE

 13. INCLUDE compiler directive

 14. Initialization on the declaration line

 15. In-line comments

 16. Length specification within the FUNCTION statement

 17. Length specifications within type declarations

 18. Mixing of character and noncharacter items in COMMON statements

 19. NAMELIST

 20. Noninteger alternate return values

 21. Noninteger array subscripts

 22. Numeric operands for .AND., .OR., etc.

 23. Specified common-block variables in DATA statements outside a BLOCK
     DATA subroutine

 24. STRUCTURE, UNION, MAP statements

 25. Up to 99 continuation lines

 26. Use of dollar sign ($) in names

 27. .XOR. operator


 548. IBM SAA Extensions Available with FORTRAN 5.00

 Product Version(s): 5.00   | 5.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified:  7-DEC-1989    ArticleIdent: Q50505

 Microsoft FORTRAN 5.00 includes all IBM SAA extensions. These
 extensions are listed below (this list can also be found on Pages
 330-331 of the "Microsoft FORTRAN Reference" manual for Version 5.00):

  1. 31 character names

  2. Bit manipulation intrinsic

  3. Case insensitive source

  4. COMMON allows character and noncharacter in same block

  5. CONJG, HFIX, IMAG intrinsic functions

  6. Data initialization in type statements

  7. EQUIVALENCE allows association of character and noncharacter

  8. Functions IOR, IAND, NOT IEOR, ISHFT, BTEST, IBSET, and IBCLR

  9. IMPLICIT NONE

 10. INCLUDE compiler directive

 11. INTEGER*2, COMPLEX*16, and LOGICAL*1 data types

 12. Optional length specifications in INTEGER, REAL, COMPLEX, and
     LOGICAL type statements

 13. Use of underscore (_) in names

 14. Z edit descriptor


 549. FORTRAN Err Msg: Cannot Open Module Definitions Field

 Product Version(s): 5.00   | 5.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | def file
 Last Modified:  7-DEC-1989    ArticleIdent: Q50583

 The L1092 'cannot open module-definitions file' link error occurs if
 some input is inadvertently given on the Definitions File prompt
 during linking, or if a response file inadvertently feeds input to the
 Definitions File prompt.

 The Definitions File field in the linker prompt should be used only
 when working with DLL's under OS/2. If the program is to be run under
 DOS, this field should be left blank.

 A semicolon at this prompt is treated as a null input.

 Section 13.2.2 of the "Microsoft FORTRAN CodeView and Utilities User's
 Guide" for Version 5.00 contains more information about linking with
 the LINK Command Line.


 550. FORTRAN Err Msg: "L1093 Object Not Found", Wrong Environment

 Product Version(s): 4.00 4.01 4.10 | 5.00
 Operating System:   MS-DOS         | OS/2
 Flags: ENDUSER |
 Last Modified:  7-DEC-1989    ArticleIdent: Q50585

 The L1093 error "object not found" can occur if the environment is
 incorrectly set. For example, the L1093 error occurs if the fl
 environment variable is specified as follows:

 set fl=options

 or

 set fl=\FPi \Zi

 In the first case, the linker thinks it needs to link in an
 OPTIONS.OBJ file. In the second case, backslashes were used for the
 command switches instead of forward slashes. In the second case, the
 linker also thinks it needs to link in the \FPi.obj and \Zi.obj files.


 551. Compilation Errors with FORTRAN 5.00, $FREEFORM, Graphics

 Product Version(s): 5.00   | 5.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified:  8-DEC-1989    ArticleIdent: Q50595

 If the $FREEFORM metacommand is placed at the top of a FORTRAN Version
 5.00 file that makes calls to the FORTRAN graphics library, you get
 compilation errors. The files FGRAPH.FI and FGRAPH.FD are not written
 to conform to the $FREEFORM format.

 If you must use the $FREEFORM metacommand, you must modify these two
 files. We recommend that you create customized include files that
 contain only the information that pertains to the graphics routines
 you are calling.

 The following is an example of a subroutine that uses the $FREEFORM
 metacommand and calls a subroutine in the FORTRAN graphics library:

 $FREEFORM
 include 'OHMAN.FI'
 subroutine foo()
 include 'OHMAN.FD'
 call setlinestyle(#AA3C)
 end

 For this particular example, the file OHMAN.FI contains information
 from the file FGRAPH.FI that pertains to the subroutine setlinestyle.
 This file, OHMAN.FI, looks like the following:

 INTERFACE TO SUBROUTINE setlinestyle[FAR,C,ALIAS:"__setlinestyle"] (mask)
 INTEGER*2 mask
 END

 Likewise, the file OHMAN.FD contains information from the file
 FGRAPH.FD that pertains to the subroutine setlinestyle. It looks like
 the following:

       EXTERNAL setlinestyle


 552. OS/2 Graphic Routines Available with FORTRAN 5.00 GRTEXTP.LIB

 Product Version(s): 5.00
 Operating System:   OS/2
 Flags: ENDUSER | Advanced Topics Manual Page 148
 Last Modified:  7-DEC-1989    ArticleIdent: Q50600

 The OS/2 graphics library GRTEXTP.LIB supports the following routines:

    clearscreen         getvisualpage       settextwindow
    displaycursor       outtext             setvideomode
    getactivepage       setactivepage       setvideomoderows
    getbkcolor          setbkcolor          setvisualpage
    gettextcolor        settextcolor        wrapon
    gettextcursor       settextcursor
    gettextposition     settextposition
    getvideoconfig      settextrows

 This library must be linked instead of GRAPHICS.LIB to use these
 routines under OS/2. Routines not included in the above list are not
 available under OS/2.

 The OS/2 Presentation Manager can be programmed to use additional
 graphics routines under OS/2.


 553. Need INTERFACE Statement to Pass Address of Common Block to C

 Product Version(s): 5.00   | 5.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | docerr
 Last Modified:  7-DEC-1989    ArticleIdent: Q51245

 Section 5.3.5.1 on Page 111 of "Microsoft FORTRAN Advanced Topics"
 manual for Version 5.00 shows a code fraction, which demonstrates
 passing of the address of a FORTRAN Common Block to C. However, the
 requirement that you must also write an INTERFACE statement to the C
 subroutine to successfully pass the address is omitted in the manual.

 For the example on Page 111, either one of the following INTERFACE
 statements works correctly:

            INTERFACE TO SUBROUTINE INITCB [C] (N)
            INTEGER*2 N [REFERENCE]
            END

 or

            INTERFACE TO SUBROUTINE INITCB [ALIAS:_initcb]
            INTEGER*2 N
            END

 In the first INTERFACE statement, the REFERENCE attribute must be
 included because C attribute otherwise causes parameter N to be passed
 by value.


 554. FORTRAN Err Msg: Filename.for(9): Error F2725 Illegal Input...

 Product Version(s): 5.00   | 5.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified:  7-DEC-1989    ArticleIdent: Q51284

 The code below produces the following error on the READ line:

    filename.for(9) : error F2725 illegal input list item

 According to Page 218 of the "Microsoft FORTRAN Reference" for Version
 5.00, declaration of an array of records is allowed. Page 214 states
 that the iolist may contain structure elements. If LIMIT is changed to
 a single structure instead of an array of structures, the code
 compiles correctly.

 Microsoft has confirmed this to be a problem in Version 5.00 of the
 compiler and will post new information as it becomes available.

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

       structure /speclimit/
       real*4  a
       end structure

       record /speclimit /limit(5)
       n=1
       limit(N).a=34.56
       read (*,1000) limit(N).a    !array causes error
 1000  format (f6.2)
       end


 555. Monitoring the Stack Using Assembly or C

 Product Version(s): 4.00 4.10 5.00 | 4.00 4.10 5.00
 Operating System:   MS-DOS         | OS/2
 Flags: ENDUSER | debug watch view
 Last Modified:  7-DEC-1989    ArticleIdent: Q51294

 If, for any reason, you believe that the stack in a FORTRAN program is
 being corrupted, you can monitor the stack segment (SS) register and
 stack pointer (SP) register by using either the Microsoft Assembler or
 the QuickC with Assembler package. Since CodeView may use the stack
 for its own purposes, this allows a more direct monitoring method.

 A function for each package is shown below along with the appropriate
 interface statement. Each function returns an integer*4 to FORTRAN.

 To extract the hexadecimal values from that integer, use a format
 statement something similar to the following example:

       write (*,'(1x,A7,1x,4Z,A1,4Z)')
      + 'seg:off',stackloc(),':',ISHC(stackloc(),16)

 This write statement produces video output of the following form:

  seg:off 2BC0:111A

 The assembly code and interface statement are shown below.

       interface to integer*4 function stackloc()
       end
       integer*4 stackloc

 .model large
 .code
 public stackloc
 stackloc proc
        mov dx,ss
        mov ax,sp
        ret
 stackloc endp
        end

 The equivalent interface for the following QuickC with Assembler code
 is also listed below (keep in mind that this code must be compiled
 with the /AL switch for memory model compatibility):

       interface to integer*4 function stackloc [C,
      + alias:'_stackloc'] ()
       end
       integer*4 stackloc

 int * stackloc(void)
 {
         int j[2];

         _asm {
                 mov     j[0],ss
                 mov     j[1],sp
         }
         return j;
 }


 556. FORTRAN Err Msg: F4998: Variable Used But Not Defined

 Product Version(s): 5.00   | 5.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified:  7-DEC-1989    ArticleIdent: Q51295

 The FORTRAN Version 5.00 compiler will produce the following error
 when the variable is defined yet not used anywhere in the program
 other than in an intrinsic function:

    F4998: variable used but not defined

 To eliminate this warning, use the variable somewhere in the program
 other than just in the intrinsic function.

 The following program generates this warning error.

       integer tmp
       write (*,*) locfar(tmp)

 To eliminate this warning, set tmp equal to something before it is
 used in the program.

       integer tmp
       tmp=1
       write (*,*) locfar(tmp)

 The following is the current list of tested intrinsic functions that
 generate this error, although many more intrinsic functions are
 believed to generate this warning:

    locfar, loc, locnear, not, ior, sin, tan, exp, log, sqrt, max, mod,
    abs

 Microsoft is researching this problem and will post new information as
 it becomes available.


 557. String Replacement Macro for M Editor

 Product Version(s): 5.00
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified:  7-DEC-1989    ArticleIdent: Q51296

 The following example illustrates a macro that can be placed within
 the TOOLS.INI file to enable the replacement of a string(string1) with
 another string(string2). The macro is assigned to a function key (F5).

 The search and replace is conducted from the position of the cursor
 down through the end of the file.

 Macro
 -----

      MacRep:=Replace "string1" newline "string2" newline
      MacRep:F5


 558. FORPATCH Available in Software/Data Library

 Product Version(s): 5.00   | 5.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | softlib FORPATCH.ARC
 Last Modified:  7-DEC-1989    ArticleIdent: Q51298

 There is a file in the Software/Data Library called FORPATCH that
 consists of a README file and a patched version of the first pass of
 the FORTRAN Version 5.00 compiler (F1.EXE) and a patched,
 high-capacity compiler (F1L.EXE).

 This update corrects the following problems:

 1. The I/O of the STRUCTURE element generates an F1001 Internal
    Compiler Error in omf_ms.c:1.118, line 1093, or a protection
    violation.

 2. NAMELIST statements in multiple subprograms in one file cause the
    machine to hang.

 3. SAVEing a common block in multiple subprograms causes a compiler
    error F2348: already declared SAVE.

 4. Using /4Yi, /4Ys, or /4Yv, and an asterisk in column one to
    indicate a comment generates a compiler error F2037: illegal label
    field.

 This file can be found in the Software/Data Library by searching on
 the keyword FORPATCH, the Q number of this article, or S12450.
 FORPATCH was archived using the PKware file-compression utility.

 This patch, called "FORTRAN 5.0 F1.EXE and F1L.EXE Patch," is also
 available from Microsoft Product Support Services at (206) 454-2030.


 559. F1001 Error 'getattrib.c:1.4' line 174, Using LOC Functions

 Product Version(s): 5.00   | 5.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | buglist5.00
 Last Modified: 31-AUG-1990    ArticleIdent: Q65261

 The following error

    fatal error F1001: Internal Compiler Error
    (compiler file '@(#)getattrib.c:1.4', line 174)

 occurs when using the LOC, LOCNEAR, or LOCFAR intrinsic function with
 a Structure-Type as an argument. This should produce a compiler error
 because Structure-Types are used to define new data types and are not
 variables. Structure Variables are defined by a RECORD statement, and
 are legal arguments to a LOC function.

 Microsoft has confirmed this to be a problem in FORTRAN version 5.00.
 We are researching this problem and will post new information here as
 it becomes available.

 The following sample code generates an internal compiler error:

       STRUCTURE /smallst/
         CHARACTER*1 letter
       END STRUCTURE

       i = LOC(smallst)
       END

 The correct use of the LOC function is as follows:

       STRUCTURE /smallst/
         CHARACTER*1 letter
       END STRUCTURE
       RECORD /smallst/ alphabet

       i = LOC(alphabet)
       END


 560. Data Type Conversion Utilities in FORTRAN 5.00

 Product Version(s): 5.00   | 5.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified:  2-MAR-1990    ArticleIdent: Q51471

 This article lists FORTRAN 5.00 data type conversion utilities. It
 includes information on the following:

 1. Intrinsic functions dealing with data type conversions, documented
    on Pages 240-241 of the "Microsoft FORTRAN Reference" manual for
    Version 5.00

 2. The $STORAGE metacommand, documented on Pages 34 and 308 of the
    "Microsoft FORTRAN Reference" manual for Version 5.00

 3. The IMPLICIT statement, documented on Pages 8 and 181-182 of the
    "Microsoft FORTRAN Reference" manual for Version 5.00

 4. Internal READ and WRITE, documented on Pages 77-78 of the
    "Microsoft FORTRAN Reference" manual for Version 5.00

 1. Intrinsic Functions
    -------------------

       Function   Description
       --------   -----------

       INT        Converts integer, real or complex arguments to
                  integers

       INT1       Converts integer, real or complex arguments to
                  INTEGER*1

       INT2       Converts integer, real or complex arguments to
                  INTEGER*2

       INT4       Converts integer, real or complex arguments to
                  INTEGER*4

       INTC       Converts integer, real or complex arguments to
                  C language integers

       IFIX       Converts REAL*4 arguments to integers

       HFIX       Converts integer, real or complex arguments to
                  INTEGER*2

       JFIX       Converts integer, real or complex arguments to
                  INTEGER*4

       IDINT      Converts DOUBLE PRECISION or REAL*8 arguments to
                  integers

       REAL       Converts integer, real or complex arguments to
                  REAL*4

       DREAL      Converts COMPLEX*16 arguments to REAL*8

       FLOAT      Converts integer arguments to REAL*4

       SNGL       Converts REAL*8 arguments to REAL*4

       DBLE       Converts integer, real or complex arguments to
                  DOUBLE PRECISION

       DFLOAT     Converts integer, real or complex arguments to
                  DOUBLE PRECISION

       CMPLX      Converts integer, real or complex arguments to
                  COMPLEX*8

       DCMPLX     Converts integer, real or complex arguments to
                  COMPLEX*16

       ICHAR      Converts character arguments to integers (ASCII
                  value)

       CHAR       Converts integer arguments to characters (ASCII
                  equivalent)

       The documentation on the data type conversion intrinsic
       functions can be found on Pages 240-241 in the "Microsoft
       FORTRAN Reference" manual for Version 5.00.

 2. $STORAGE Metacommand
    --------------------

    $STORAGE:n allocates n bytes of memory for all variables declared
    as INTEGER or LOGICAL. For example, if INTEGER B variable
    declaration is used and the $STORAGE:2 metacommand is specified, B
    will be allocated 2 bytes instead of 4. $STORAGE does not affect
    the allocation of memory for variables declared with an explicit
    length specification, such as INTEGER*2 or INTEGER*4. The $STORAGE
    metacommand is documented on Pages 34 and 308 of the "Microsoft
    FORTRAN Reference" manual for Version 5.00.

 3. IMPLICIT Statement
    ------------------

    If a name is not explicitly defined, the first letter of a variable
    or function determines its type. By default, names starting with I,
    J, K, L, M, or N are given the type INTEGER, while variables
    starting with any other letter or a dollar sign are given the type
    REAL. An IMPLICIT statement can be used to override the default. An
    explicit type declaration overrides the type established by the
    IMPLICIT statement. The IMPLICIT statement is documented on Pages
    8 and 181-182 of the "Microsoft FORTRAN Reference" manual for
    Version 5.00.

 4. Internal READ and WRITE
    -----------------------

    Reading from an internal file converts the ASCII values into
    numeric, logical, or character values, and writing to an internal
    file converts values into their ASCII representations. Internal
    READ and WRITE are documented on Pages 77-78 of the "Microsoft
    FORTRAN Reference" manual for Version 5.00. The following code
    sample converts a character variable into an integer:

       character*5 num
       integer test
       num='12345'
       read(num,'(i5)') test
       write (*,*) test
       end


 561. Incorrect INTEGER Size Listed in Reference Manual, Page 191

 Product Version(s): 5.00   | 5.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | docerr
 Last Modified:  7-DEC-1989    ArticleIdent: Q51492

 The last line on Page 191 of the "Microsoft FORTRAN Reference" manual
 for Version 5.00 incorrectly reads as follows:

        INTEGER*22 q, m12*24, ivec(10)*24, z*24(10)

 Four extraneous 2s should be removed from the line as follows:

        INTEGER*2 q, m12*4, ivec(10)*4, z*4(10)


 562. Including BSE.FD Twice Causes Protection Violation

 Product Version(s): 5.00
 Operating System:   OS/2
 Flags: ENDUSER | buglist5.00
 Last Modified:  7-DEC-1989    ArticleIdent: Q51494

 The FORTRAN Version 5.00 compiler causes a protection violation, after
 a number of other errors, when the following code is compiled. It
 seems to have problems with the include files. If the files were
 entered properly, there would be both an "fi" and an "fd" include
 file. BSE.FD is included on the FORTRAN 5.00 OS/2 Support Disk 2.

 Example
 -------

 C **************************
       include 'bse.fd'
       include 'bse.fd'
       x = dosbeep(200,200)
       write (*,*) x
       stop
       end


 563. Use of ICHAR and CHAR Intrinsic Functions

 Product Version(s): 4.10 5.00 | 4.10 5.00
 Operating System:   MS-DOS    | OS/2
 Flags: ENDUSER | type conversion
 Last Modified:  7-DEC-1989    ArticleIdent: Q51495

 The ICHAR intrinsic function converts a single character to the
 integer ASCII value of that character.

 The CHAR intrinsic function converts an integer to the corresponding
 ASCII character.

 In both cases, ICHAR and CHAR use decimal integer values and the
 Extended ASCII Character Set.

 The ICHAR function will not directly convert a number that is stored
 as a character to the same number stored as an integer.

 The integer in both cases must be between 0 and 255. A number larger
 than 255 will "wrap around" to a value between 0 and 255, e.g. 256
 would be interpreted as 0, 257 as 1, 511 as 255, etc.

 The character string in both cases must be a single character
 (CHARACTER*1). If the character string is longer than one (CHARACTER*2
 or more), the functions will recognize only the first character
 position and ignore the rest.

 Example of ICHAR and CHAR
 -------------------------

       PROGRAM example

       INTEGER*2   int1, int2
       CHARACTER*1 char1, char2

       char1 = 'A'
       int1  = ICHAR(char1)

       int2  = 90
       char2 = CHAR(int2)

       write(*,*) 'char1 = ',char1,' and int1 = ',int1
       write(*,*) 'char2 = ',char2,' and int2 = ',int2

       end

 The output of program example is as follows:

    char1 = A and int1 =          65
    char2 = Z and int2 =          90

 The values 65 and 90 are the corresponding ASCII decimal values for
 the capital characters A and Z, respectively.

 The ICHAR and CHAR intrinsic functions are described on Pages 240-241
 of the "Microsoft FORTRAN Reference" manual for Version 5.00 and on
 Pages 323 and 325 of the "Microsoft FORTRAN 4.1 Optimizing Compiler:
 Language Reference."


 564. Example of Using a BLOCK DATA Subprogram

 Product Version(s): 5.00   | 5.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | docerr
 Last Modified:  7-DEC-1989    ArticleIdent: Q51496

 A BLOCK DATA subprogram must come at the beginning of a main program
 file prior to the PROGRAM statement or at the end of the file after
 the END statement closing the main program.

 The variables initialized by the BLOCK DATA subprogram must be typed
 within the subprogram. The BLOCK DATA examples on Page 124 in the
 "Microsoft FORTRAN Reference" manual for Version 5.00 are incorrect
 because they do not type the variables prior to initialization.

 Below is an example of a program that uses BLOCK DATA.

 The following program shows how a BLOCK DATA subprogram can be used to
 initialize variables grouped within a named common block:

 C ******** BLOCK DATA statement at beginning of file ***

       BLOCK DATA foo
         integer*2   int1
         real*4      real1
         character*2 char1
         logical     log1
         common /test/ int1, real1, char1, log1
         data int1, real1, char1, log1 /1,4.0,'ZZ',.true./
       END

 C ******** Beginning of main program *******************

       PROGRAM block

       integer*2   int1
       real*4      real1
       character*2 char1
       logical     log1

       common /test/ int1, real1, char1, log1

       write (*,100) int1, real1, char1, log1
 100   format (1X, I1, 3X, F3.1, 3X, A2, 3X, L1)

       end

 The output of the program BLOCK is as follows:

    1   4.0   ZZ   T

 In the above program example, the BLOCK DATA subprogram could have
 been placed AFTER the END statement of the main program, producing the
 same results.


 565. Fatal Error F1001: compiler file'@(#)ctypes.c:1.11', line 448

 Product Version(s): 5.00   | 5.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | buglist5.00
 Last Modified:  7-DEC-1989    ArticleIdent: Q51507

 The following example using double parentheses causes an internal
 compiler error. To work around the problem, remove the double
 parentheses.

 If the /Fs switch is used on the FORTRAN command line, a protection
 violation is generated under OS/2, or a system lockup occurs under
 DOS.

 Example
 -------

       program papa
       character*10 a
       a='1234567890'
       call mama((a(4:8)))  ! Remove the outer parenthesis
       stop
       end

       subroutine mama(b)
       character*5 b
       write (*,*) b
       return
       end

 The errors generated are similar to the following (this file was named
 subroti.for):

    subroti.for(5) : fatal error F1001: Internal Compiler Error
              (compiler file '@(#)ctypes.c:1.11', line 448)
              Contact Microsoft Technical Support


 566. Creating a Pointer in FORTRAN

 Product Version(s): 5.00   | 5.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified:  2-MAR-1990    ArticleIdent: Q51607

 The two sample programs below demonstrate a way to simulate pointers
 in FORTRAN. The first is for DOS and the second is for OS/2.

 Example 1
 ---------

 c This program demonstrates the use of a pointer in FORTRAN
 c 5.00 in DOS. This program loads a far address into an
 c integer*4 and passes that to a subroutine.
 c
 c Next, an INTERFACE TO SUBROUTINE is used to "lie" to FORTRAN
 c about what is being passed. The interface tells FORTRAN
 c that it is passing an integer*4 by value. The actual
 c subroutine, which is referred to by the ALIAS attribute,
 c expects a far address to an array. The value of the
 c integer*4 is that address. Once inside that subroutine,
 c The entire segment can be accessed by specifying the
 c correct index to the array.
 c
 c The subroutine SETPOINT2 changes the screen attribute byte
 c to cause the characters on the video display to blink.

          interface to subroutine setpoint[alias:'setpoint2'] (abc)
            integer*4   abc  [value]
          end

          subroutine setpoint2 (abc)
             integer*2   abc(*),n

             do 100,n=1,2000
             abc(n)=ior(abc(n),#8000)
 100         continue
          end

          program graphtest
             integer*4      ptr

             ptr=#0b8000000
             write (*,'(z9)') ptr
             call setpoint (ptr)
          end

 Example 2
 ---------

 c This program demonstrates the use of a pointer in FORTRAN
 c 5.00 in OS/2. This particular program gets a selector to
 c the video buffer from the DOS function call VioGetPhysBuf().
 c Once the selector is acquired, it is converted to a far
 c pointer by shifting it 16 positions to the left.
 c
 c Next, an interface to subroutine is used to lie to FORTRAN
 c about what it is passing. The interface tells FORTRAN that
 c it is passing an integer*4 by value. The actual
 c subroutine, which is referred to by the ALIAS attribute,
 c expects a far address to an array. The value of the
 c integer*4 is that address. Once inside that subroutine,
 c The entire segment can be accessed by specifying the
 c correct index to the array.
 c
 c The subroutine SETPOINT2 changes the attribute byte to
 c cause the characters on the video display to blink.

          interface to function viogetphysbuf (buffer,handle)
              structure/buffstrc/
                integer*4  address
                integer*4  length
                integer*2  selector
              end structure
              record/buffstrc/buffer
              integer*2    handle   [value]
              integer*2    viogetphysbuf
          end

          interface to subroutine setpoint[alias:'setpoint2'] (abc)
            integer*4   abc  [value]
          end

          subroutine setpoint2 (abc)
             integer*2   abc(*),n

             do 100,n=1,2000
             abc(n)=ior(abc(n),#8000)
 100         continue

          end

          program graphtest

             structure/buffstrc/
                integer*4  address
                integer*4  length
                integer*2  selector
             end structure
             record/buffstrc/buffer

             integer*2      error,viogetphysbuf
             integer*4      ptr

             buffer.address = #0b8000
             buffer.length  = 4000

             error=viogetphysbuf (buffer,0)

             ptr=isha(buffer.selector,16)
             write (*,'(z10,i3)') ptr,error
             call setpoint (ptr)
          end


 567. Entry Point and F1001 in omf_ms.c, Line 1093

 Product Version(s): 4.10   | 5.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | buglist4.10 buglist5.00
 Last Modified:  2-MAR-1990    ArticleIdent: Q51608

 Microsoft FORTRAN Versions 4.10 and 5.00 may produce the following
 fatal error under DOS or a protection violation under OS/2 if an
 executable statement contains a variable that is later used as a
 formal parameter in an ENTRY statement:

    F1001 : Internal Compiler Error
    (compiler file '@(#)omf_ms.c:1.118',line 1093)

 This programming practice is not allowed in FORTRAN. The
 fourth paragraph on Page 163 of the "Microsoft FORTRAN Reference"
 manual for Version 5.00 states the following:

    A formal argument cannot appear in an executable statement that
    occurs before the ENTRY statement containing the formal argument
    unless the formal argument also appears in a FUNCTION, SUBROUTINE,
    or ENTRY statement that precedes the executable statement.

 The next to last paragraph on Page 208 of the "Microsoft FORTRAN 4.1
 Optimizing Compiler: Language Reference" manual contains similar
 information.

 The following code produces the above mentioned error:

       a = 100.0
       call setpt (a)
       call frstc
       stop
       end

       subroutine frstc
       write(*,*) b     !b in an executable statement
       return
       entry setpt (b)  !b as formal parameter (for first time)
       return
       end

 If "b" is declared as a formal parameter for subroutine frstc, the
 program compiles with no errors.


 568. Mixed-Language Example: Accessing FORTRAN Common from C

 Product Version(s): 5.00    | 5.00
 Operating System:   MS-DOS  | OS/2
 Flags: ENDUSER | S_C S_QUICKC
 Last Modified:  2-MAR-1990    ArticleIdent: Q51614

 The following example demonstrates how to access a FORTRAN common
 block from a C function. The common block is declared in FORTRAN as a
 common block and in C as an external structure with a FORTRAN
 attribute. The common block can be referenced from both languages with
 these embedded language constructs. This program must be compiled for
 medium or large model. For more information on common blocks, see Page
 110 in the "Microsoft FORTRAN Advanced Topics" manual for FORTRAN
 5.00, or Page 132 in the mixed-language programming guide that is
 included with C 5.10, Pascal 4.00, and MASM 5.10.

 ------------------------COMMON.FOR-----------------------------
 C FORTRAN calling C, program used to show how to utilize common
 C blocks in a mixed-language application. This is the FORTRAN
 C main module that will declare the common block and call the C
 C procedure to modify the contents. After, it will display the
 C new common block values.
 C
 C The following shared common block is called "cblock".

       integer*4 I
       real R
       character*1 Ch
       common/cblock/ I,R,Ch
 C
 C The following FORTRAN code will display the contents of "cblock"
 C before and after the call to the C function.
 C
       I=10
       R=2.0
       Ch='d'
       Write(*,10) I,R,Ch
       call cproc
       Write(*,10) I,R,Ch
  10   format(1x,I3,1x,F7.2,1x,A)
       end
 ------------------------CBLOCK.C-------------------------------
 /*
   The C code declares a structure to look like a FORTRAN common
   block. This structure is declared extern with the FORTRAN
   attribute. Any common block can be declared the same way. The
   C function "cproc" simply assigns values to the elements in the
   common block (C structure).
  */

 struct mystruct { long i;
                   float f;
                   char c; };

 extern struct mystruct  cblock;

 void fortran cproc(void)
 {
   cblock.i = 100;
   cblock.f = 100.00;
   cblock.c = 'A';
 }
 ------------------------COMMON.MAK----------------------------
 # This make file will build the executable program COMMON.EXE.
 # The program is compiled for large or medium memory model and it
 # will include CodeView information. It is linked with no default
 # libraries and no extended dictionary search. This MAKE file can
 # be executed by typing:
 #
 #        MAKE common.mak
 # or
 #        NMAKE -f common.mak

 MODEL=L

 # The following line can be deleted if using MAKE.
 ALL : common.exe

 common.obj : common.for
   fl /Zi /A$(MODEL) /c $**

 cblock.obj : cblock.c
   cl /Zi /A$(MODEL) /c $**

 common.exe : common.obj cblock.obj
   link $** /nod /noe,,,$(MODEL)libfer.lib $(MODEL)libcer.lib;


 569. MODE='WRITE' Does Not Work with ACCESS='APPEND'

 Product Version(s): 5.00   | 5.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | buglist5.00
 Last Modified:  2-MAR-1990    ArticleIdent: Q51749

 ACCESS='APPEND' does not work correctly if MODE='WRITE' is also
 included as one of the options in an OPEN statement. Under MS-DOS,
 instead of appending to a file, the file to be appended to is either
 partly or completely overwritten. Under OS/2, the following run-time
 error may be incorrectly generated:

    F6421:WRITE(test.dat) - file read-only or locked against writing

 Code Sample #1 -- Create TEST.DAT File
 --------------------------------------

 The following code creates a file TEST.DAT:

            integer a,b,c
            open (12,file='test.dat',status='new',mode='write')
            a = 10
            b = 20
            c = 30
            write (12,*) a,b,c
            end

 Code Sample #2 -- Append to TEST.DAT Fails
 ------------------------------------------

 The following code is supposed to append to TEST.DAT. However, the
 file is overwritten under MS-DOS, and the following run-time error is
 generated under OS/2:

    F6421:WRITE(test.dat) - file read-only or locked against writing

         integer a,b,c
         open (11,file= 'test.dat',access='append',
      +       mode='write')
         a = 1
         b = 2
         c = 3
         write (11,*) a,b,c
         end

 Code Sample #3 -- Append Works If MODE='WRITE' Is Removed
 ---------------------------------------------------------

 When MODE='WRITE' is removed, TEST.DAT is appended to properly, i.e.,
 the following code runs correctly:

         integer a,b,c
         open (11,file = 'test.dat',access='append')
         a = 1
         b = 2
         c = 3
         write (11,*) a,b,c
         end


 570. Dollar Sign in FORMAT Statement Equivalent to Backslash

 Product Version(s): 5.00   | 5.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | docerr undocumented VAX extension
 Last Modified:  2-MAR-1990    ArticleIdent: Q51750

 A dollar sign ($) can be used in a FORMAT statement to suppress the
 carriage-control character. It functions the same as the backslash
 edit descriptor (\). It is used for formatted I/O to terminal devices,
 such as the screen or a printer. It is ignored in all other
 situations.

 Backslash editing is described on Page 84 of the "Microsoft FORTRAN
 Reference" manual for Version 5.00.


 571. PC Kwik RAM Disk May Cause Internal Compiler Errors

 Product Version(s): 5.00
 Operating System:   MS-DOS
 Flags: ENDUSER | F1001
 Last Modified:  2-MAR-1990    ArticleIdent: Q57303

 The PC Kwik RAM disk software shipped with the Dell System Enhancement
 package for DOS Version 4.00 may cause spurious internal compiler
 errors when compiling with the Microsoft FORTRAN Compiler Version
 5.00.

 This problem was reported by a customer whose TMP environment variable
 pointed to the RAM disk.  Pointing the TMP variable to the hard disk
 corrected the problem.


 572. Statement Function Changes from FORTRAN 3.x to 4.x and 5.00

 Product Version(s): 3.x 4.00 4.01 5.00 | 4.10 5.00
 Operating System:   MS-DOS             | OS/2
 Flags: ENDUSER | softlib STATFUNC.ARC
 Last Modified:  2-MAR-1990    ArticleIdent: Q57551

 The statement function defines a function in a single statement.

 There was a change in the internal operation of the statement function
 between Versions 3.x of FORTRAN and Versions 4.x and 5.00.

 In Versions 3.x, the code for the function generated by the statement
 function is generated once, and each use of the function generates a
 call to that code.

 In Versions 4.x and later, the code is inserted each time the function
 is called. This will increase code size, but cause faster operation.

 There is a file in the Software Library named STATFUNC that shows
 examples of the statement function in FORTRAN for Versions 3.31 and
 5.00. STATFUNC can be found in the Software/Data Library by searching
 on the keyword STATFUNC, the Q number of this article, or S21507.
 STATFUNC was archived using the PKware file-compression utility.


 573. MOVETO_W INTERFACE Statement Documentation Error

 Product Version(s): 5.00   | 5.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | docerr moveto graphics
 Last Modified:  2-MAR-1990    ArticleIdent: Q57570

 There is a documentation error on Page 230 of the "Microsoft FORTRAN
 Advanced Topics" manual for Version 5.00.

 The INTERFACE statement to subroutine MOVETO_W specifies that the
 first two parameters passed to subroutine MOVETO_W should be of type
 INTEGER*2. This is incorrect, they should be of type DOUBLE PRECISION.

 The INTERFACE statement in the include file FGRAPH.FI is correct.

 The correct INTERFACE statement reads as follows:

        INTERFACE TO SUBROUTINE
       +moveto_w[FAR,C,ALIAS:"__f_moveto_w"](wx,wy,s)
        DOUBLE PRECISION wx,wy     !manual incorrect here
        STRUCTURE/wxycoord/
         DOUBLE PRECISION wx
         DOUBLE PRECISION wy
        END STRUCTURE
        RECORD/wxycoord/s[FAR,REFERENCE]
        END


 574. Passing Variables with the SYSTEM Call

 Product Version(s): 4.10 5.00 | 4.10 5.00
 Operating System:   MS-DOS    | OS/2
 Flags: ENDUSER |
 Last Modified:  2-MAR-1990    ArticleIdent: Q57571

 The C function, SYSTEM, is available within the FORTRAN Run Time
 Library. It is possible to pass a variable argument within that
 function call. The variable can also be a concatenated variable. Below
 is an example demonstrating this feature.

 Note: SYSTEM is a C function within the FORTRAN Library. Any
 limitation or characteristics that are encountered are those of the C
 convention and not of FORTRAN (for example, null terminated strings).

 c...This program will demonstrate the use of a concatenated
 c...variable argument for the SYSTEM function call. It has
 c...the same effect as typing DIR *.FOR at the DOS prompt.

 c..Interface statement

       interface to integer*2 function system[c]
      +(string[reference])
       character*1 string
       end

 c..Variable set up and function call

       integer*2 system
       character*4 foo
       character*5 bar
       character*9 all
       foo='dir'
       bar='*.for'c   ! c treats this as a null terminated C string
       all=foo//bar   ! Concatenate the string as 'dir *.for'
       i=system(all)  ! Pass a variable to SYSTEM
       end


 575. Formatted I/O, Carriage Control Characters, and LPT2

 Product Version(s): 5.00   | 5.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | buglist5.00
 Last Modified:  2-MAR-1990    ArticleIdent: Q57572

 The section on "Carriage Control" on Page 78 of the "Microsoft FORTRAN
 Reference" manual for Version 5.00 states the following:

    When formatted I/O is used to transfer a record to a terminal
    device, such as screen or printer, the first character of that
    record is interpreted as a carriage control character, and is not
    printed.

 This is not true for printers connected to LPT2. Thus, the carriage
 control characters listed on Page 79 of the FORTRAN 5.00 reference
 manual will not be interpreted properly for the printers connected to
 LPT2.

 Microsoft has confirmed this to be a problem in Version 5.00. We are
 researching this problem and will post new information as it becomes
 available.

 The following program is supposed to form feed and then print "5
 years". However, it does not form feed and it prints "15 years":

       open (10, file='LPT2', status='OLD')
       write(10,200)
 200   format ('15 years')
       end

 To work around this problem, either change 'LPT2' to 'LPT1' in the
 OPEN statement and connect the printer to LPT1, or use the CHAR
 function to send the carriage control characters to the printer on
 LPT2. The following code sample demonstrates the second workaround:

       open (10, file='LPT2', status='OLD')
       write(10,200) char(12)   ! Form Feed - ASCII 12
 200   format (a1,'5 years')
       end


 576. VAX/VMS FORTRAN Language Features NOT Supported in 4.10/5.00

 Product Version(s): 4.10 5.00      | 4.10 5.00
 Operating System:   MS-DOS         | OS/2
 Flags: ENDUSER | extension
 Last Modified:  2-MAR-1990    ArticleIdent: Q57592

 Below is a list of VAX/VMS FORTRAN 77 language features that Microsoft
 FORTRAN Version 4.10 does not support. Some features that require
 VAX-specific architecture support (such as keyed access files) are not
 listed.

 Those features implemented in Microsoft FORTRAN Version 5.00 are
 preceded by an asterisk (*).

    *  IMPLICIT NONE
       Many intrinsic function names (but no new functionality)
    *  NAMELIST
    *  INCLUDE STATEMENT
    *  End-of-line comments (!)
       Tabs that are treated like tabs in the source
       Continuation lines can begin with a tab
    *  DOUBLE COMPLEX keyword (COMPLEX*16 is supported)
       BYTE data type
       REAL *16
       COMMON block vars can be initialized in DATA statements before
          COMMON statement
       Octal and hexadecimal constant notation ('017'O, 'FF'X)
    *  Records and structures
       LOGICAL and INTEGER variables are interchangable
          (the complication here is that .TRUE. is odd, .FALSE. is even
          on VAX)
    *  .AND., .OR., .XOR., etc. allow numeric arguments
       VOLATILE statement
       Some intrinsic functions are allowed in PARAMETER expressions
       DO  ...   END DO
    *  DO WHILE
       %LOC
       %REF, %VAL, %DESCR
       FUNCTION length specifications  (e.g. INTEGER FUNCTION FUN*2)
       ACCEPT and TYPE statements
       REWRITE statement
       Variable format descriptors
       O, $ edit descriptors
       OPEN statement keywords:
          ASSOCIATEVARIABLE
          DEFAULTFILE
          DISP[OSE]
          NAME
          MAXREC
          ORGANIZATION
          READONLY
          RECORDSIZE  (a synonym for RECL)
       CLOSE statement DISP[OSE] keyword
       READ(iunit'irec) syntax for direct access files
       INQUIRE statement keywords:
              DEFAULTFILE
              ORGANIZATION
    *  OPEN append

       FORTRAN 66 leftovers:
              ENCODE, DECODE statement
              DEFINE FILE
              FIND
              Old PARAMETER syntax and semantics


 577. MAXEXPONENT Function Documentation Error

 Product Version(s): 5.00   | 5.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | docerr
 Last Modified:  2-MAR-1990    ArticleIdent: Q57608

 Page 242 of the "Microsoft FORTRAN Reference" manual for Version 5.00
 incorrectly states that the return value of the MAXEXPONENT function
 is 38.

 The MAXEXPONENT function actually returns 308.


 578. Conversion Functions from BCD (DECMATH.LIB) to IEEE Formats

 Product Version(s): 3.20 3.30 3.31 4.10 5.00 | 4.10 5.00
 Operating System:   MS-DOS                   | OS/2
 Flags: ENDUSER | softlib BCD2IEEE.ARC
 Last Modified:  2-MAR-1990    ArticleIdent: Q57871

 There is a file in the Software/Data Library named BCD2IEEE that
 includes Microsoft FORTRAN 5.0 source code for conversion between
 Binary Coded Decimal (BCD) floating-point format (used in FORTRAN Versions
 3.20, 3.30, and 3.31 DECMATH.LIB) and IEEE floating-point format (used in
 the Version 4.00, 4.01, 4.10, and 5.00 coprocessor and emulator libraries).

 BCD2IEEE can be found in the Software/Data Library by searching
 on the keyword BCD2IEEE, the Q number of this article, or S12521.
 BCD2IEEE was archived using the PKware file-compression utility.

 BCD2IEEE includes the following files:

    File           Description
    ----           -----------

    SDECCVT        A FORTRAN function that converts Binary Coded Decimal
                   floating-point format for single-precision real
                   numbers to IEEE floating-point format for
                   single-precision reals

    SDECTST.FOR    A FORTRAN program to demonstrate the use of SDECCVT

    DDECCVT        A FORTRAN function that converts Binary Coded Decimal
                   floating-point format for double-precision reals to
                   IEEE floating-point format for double-precision
                   reals

    DDECTST.FOR    A FORTRAN program to demonstrate the use of DDECCVT


 579. Handling Floating-Point Exceptions

 Product Version(s): 3.30 3.31 4.00 4.01 4.10 5.00 | 4.10 5.00
 Operating System:   MS-DOS                        | OS/2
 Flags: ENDUSER |
 Last Modified:  2-MAR-1990    ArticleIdent: Q57918

 Section 1.5 of the "Microsoft FORTRAN Advanced Topics" manual for the
 Microsoft FORTRAN Optimizing Compiler Version 5.00 describes how the
 five exceptions of floating-point arithmetic required by the IEEE
 standard can be controlled. Similar information is contained in
 Appendix D of the "Microsoft FORTRAN 4.1 Optimizing Compiler: User's
 Guide" for Versions 4.x and Appendix F of the "Microsoft FORTRAN
 User's Guide" for Versions 3.3x.

 These exceptions are invalid operation, divide by zero, overflow,
 underflow, and precision. The following three routines, provided in
 the FORTRAN run-time library, allow you to obtain and set the value of
 the status and control words:

    The store-status-word (SSWRQQ) function returns the value of
    the status word.

    The store-control-word (SCWRQQ) function returns the value
    of the control word.

    The load-control-word (LCWRQQ) function set the control word
    to a certain value.

 The following program demonstrates usage of the LCWRQQ function to
 disable overflow and zero divide run-time errors:

      INTERFACE TO SUBROUTINE LCWRQQ(CW)
      INTEGER*2 CW
      END

      PROGRAM NOEXCEPTIONS

      INTEGER*2 CW
      PARAMETER(CW=16#133F)
      REAL*4 X,Y,Z

      X = 1.0
      Y = 0.0

      CALL LCWRQQ(CW)

      Z = X / Y

      END


 580. Internal Compiler Error: '@(#)omf.c:1.60', Line 185

 Product Version(s): 5.00
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist5.00
 Last Modified:  2-MAR-1990    ArticleIdent: Q58322

 The program below causes the following internal compiler error:

    fatal error F1001: Internal Compiler Error
                   (compiler file '@(#)omf.c:1.60', line 185)
                   Contact Microsoft Technical Support

 The program defines a common block of arrays that spans three
 segments. The program then initializes the arrays of the common block
 to zero. The error is generated because the program is initializing
 the arrays in a different order than they are specified in the common
 block.

 The workaround is to initialize the arrays in the same order that they
 appear in the common block.

 Microsoft is currently researching the problem and will post new
 information as it becomes available.

 The following program demonstrates the internal compiler error:

 C ============ FORTRAN SOURCE CODE == Fragment #1 ===============

       real*8 test1[huge](225,100), test2(300), test3(300)

       common /test/ test1, test2, test3

       data test3 /300*0/
       data test1 /22500*0/

       end
 C ===============================================================

 The workaround is to initialize the arrays in the order they appear in
 the common block as seen below.

 C ============ FORTRAN SOURCE CODE == Fragment #2 ===============

       real*8 test1[huge](225,100), test2(300), test3(300)

       common /test/ test1, test2, test3

       data test1 /22500*0/
       data test3 /300*0/

       end
 C ===============================================================


 581. Strange Characters in MAP File on 27th Segment Name and Above

 Product Version(s): 5.00   | 5.00
 Operating System:   MS/DOS | OS/2
 Flags: ENDUSER | S_LINK buglist5.00
 Last Modified:  2-MAR-1990    ArticleIdent: Q58394

 When looking at a MAP file that was compiled with FORTRAN Version 5.00
 that has more than 26 segments, some strange characters start
 appearing on the 27th segment name. The characters could be smiley
 faces, diamonds, or hearts, in addition to the ASCII characters of
 132d and 128d.

 Microsoft has confirmed this to be a problem with FORTRAN 5.00 and
 linker Versions 5.03 and 5.01.20. This problem does not occur if the
 file was compiled under FORTRAN 4.10. We are researching this problem
 and will post new information as it becomes available.

 The following program demonstrates the problem:

 SOURCE CODE:
        PROGRAM strange
        COMMON /dummy/ x(500000) !makes over 26 segments
        STOP
        END

 The above program was compiled with the default options.

 The above code produces a MAP file upon link, as follows:

    Start     Length   Name             Code
    -----     ------   ----             ----

    0001:0000 00020H   STRANGE_TEXT     CODE
    0001:0020 02AB1H   _TEXT            CODE
    0001:2AD2 00000H   C_ETEXT          ENDCODE
    0002:0000 10000H   DUMMY$A          $DUMMY
     .    .     .        .                .
     .    .     .        .                .
    001B:0000 10000H   DUMMY$Z          $DUMMY
    001C:0000 10000H   DUMMY$AA###      $DUMMY
    001D:0000 10000H   DUMMY$AB###      $DUMMY
    OO1E:0000 10000H   DUMMY$AC###      $DUMMY
     .    .     .        .     ^^^        .
                                |
    These are the strange-------|
    characters.

 The strange characters usually are the ASCII characters of smiley
 faces, hearts, diamonds, an "a" with two dots over it, and a "c" with
 a squiggly line under it. These characters represent the ASCII decimal
 values of 1-4, 128, and 132.


 582. Registerfonts Function Returns -4 When Out of Memory

 Product Version(s): 5.00
 Operating System:   MS-DOS
 Flags: ENDUSER | docerr S_C S_QuickC _registerfonts
 Last Modified:  2-MAR-1990    ArticleIdent: Q58430

 The registerfonts function in the GRAPHICS.LIB graphics library may
 return a value of -4. This error code will be returned if there is not
 enough free memory to allocate space for the font(s). This return code
 should be documented on Page 239 of the "Microsoft FORTRAN Advanced
 Topics" manual for Version 5.00.

 Using the /CP:1 switch at link time may free up enough memory to
 enable registering of the font. The /CP or /CPARMAXALLOC switch limits
 the number of paragraphs the DOS loader may allocate at run-time.


 583. L1103 and Initialization of Large Common Blocks

 Product Version(s): 5.00   | 5.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | buglist5.00
 Last Modified:  2-MAR-1990    ArticleIdent: Q58431

 The program below causes the following linker error:

    fatal error L1103: attempt to access data outside segment bounds

 The program defines a common block of arrays that span multiple
 segments. The program then initializes the arrays in the common block.
 The error is generated because the program is initializing the arrays
 in a different order than they are specified in the common block.

 The workaround is to initialize the arrays in the same order that they
 appear in the common block.

 Note: It is also possible to generate an internal compiler error by
 making simple modifications to the source code mentioned above.
 However, the workaround, is the same: initialize arrays in the order
 they are defined in the common block. For an example, query on the
 following in this Knowledge Base:

    internal and compiler and error and F1001 and line and 185

 Microsoft is researching this problem and will post new information
 here as it becomes available.

 The following program demonstrates the linker error L1103:

 C ============ FORTRAN SOURCE CODE == Fragment #1 ===============

       real*8    test1, test2

       common /test/ test1(1000,10), test2(100)

       data test2 /100*0/
       data test1 /10000*0/

       end
 C ===============================================================

 The workaround is to initialize the arrays in the order they appear in
 the common block, as shown below.

 C ============ FORTRAN SOURCE CODE == Fragment #2 ===============

       real*8    test1, test2

       common /test/ test1(1000,10), test2(100)

       data test1 /10000*0/
       data test2 /100*0/

       end
 C ===============================================================


 584. Invalid Filename Causes "SHARE Not Installed" in FORTRAN 5.00

 Product Version(s): 5.00
 Operating System:   OS/2
 Flags: ENDUSER | buglist5.00
 Last Modified:  2-MAR-1990    ArticleIdent: Q59093

 Trying to open a file with an invalid file specification incorrectly
 produces the following error message in OS/2.

    run-time error F6412: OPEN(filename.ext.)
     - SHARE not installed

 In the following example, the trailing period should be removed from
 the filename specification.

      OPEN(UNIT=7,FILE='filename.ext.')
      END

 Microsoft is researching the problem and will post new information
 here as it becomes available.


 585. Character String and PARAMETER Statement

 Product Version(s): 4.01 4.10 5.00 | 4.10 5.00
 Operating System:   MS-DOS         | OS/2
 Flags: ENDUSER |
 Last Modified:  2-MAR-1990    ArticleIdent: Q59094

 When using the PARAMETER statement to define a symbolic constant, you
 can use the symbolic constant to define the length of a CHARACTER
 string. The following program demonstrates this:

     PROGRAM FOO
     parameter (length=80)
     character string_NAME*(length)
     end

 You must put the symbolic constant (LENGTH) in parentheses, or a
 syntax error will occur.


 586. PRECISION Intrinsic Function Yields Incorrect Results

 Product Version(s): 5.00   | 5.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | buglist5.00
 Last Modified:  2-MAR-1990    ArticleIdent: Q59227

 The FORTRAN intrinsic function PRECISION, which is documented on Page
 242 of the "Microsoft FORTRAN Reference" manual for Version 5.00,
 produces incorrect results when used to find the precision of a REAL
 number.

 Microsoft has confirmed this to be a problem with Microsoft FORTRAN
 Version 5.00. We are researching this problem and will post new
 information here as it becomes available.

 The PRECISION function was introduced with FORTRAN 5.00.

 The following example demonstrates this problem:

 C ===== FORTRAN source code ================================

       real*4 var1
       double precision var2

       data var1, var2 /0,0/

       write (*,*) PRECISION (var1)
       write (*,*) PRECISION (var2)

       end

 C ==========================================================

 The program output is as follows:

    15
    15

 The expected output should be as follows

     6
    15

 (that is, 6 for the real*4 and 15 for the double precision).


 587. F1912 "Cannot Open File" Caused by Nonexistent File

 Product Version(s): 4.00 4.01 4.10 5.00 | 4.10 5.00
 Operating System:   MS-DOS              | OS/2
 Flags: ENDUSER |
 Last Modified:  2-MAR-1990    ArticleIdent: Q59228

 The following error usually occurs because the file you are trying to
 compile does not exist (for example, you typed FL TXXT.FOR instead of
 FL TEST.FOR) or you are not compiling from the directory in which the
 file exists:

    fatal error F1912: (file name) : cannot open file

 To prevent this error, specify the correct filename or change to the
 directory in which the file resides, then proceed with compiling.


 588. "P" Edit Descriptor and Zero Output

 Product Version(s): 5.00   | 5.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | buglist5.00
 Last Modified:  2-MAR-1990    ArticleIdent: Q59229

 The "P" edit descriptor is described on Page 84 of the "Microsoft
 FORTRAN Reference" manual for Version 5.00.

 The "P" edit descriptor is a "scale factor" for output. It is useful
 when printing out percentages.

 When a ZERO value is printed out, it is inconsistent with the other
 values, printing an extra zero. There does not seem to be any way
 around this.

 Microsoft has confirmed this to be a problem in Version 5.00. We are
 researching this problem and will post new information here as it
 becomes available.

 The following example demonstrates the problem:

 CC When a zero value printed out, an extra zero is printed.
       var1 = 0.0000
       var2 = 0.0123
       write (*,'(2P,1x,2F10.5)') var1, var2
       end

 The following line is the incorrect output from this program:

    00.00000   1.23000

 The output of the program should be as follows:

     0.00000   1.23000


 589. "Out of Environment" Error After Language Installation

 Product Version(s): 4.00 4.01 4.10 5.00
 Operating System:   MS-DOS
 Flags: ENDUSER | Supercharging MS-DOS O_MSDOS S_C H_MASM S_PASCAL install set
 Last Modified:  2-MAR-1990    ArticleIdent: Q59230

 The MS-DOS "out of environment space" error can be caused by an
 environment that contains the following:

 1. Many directories in the command path or DOS APPEND command
 2. Many SET statements
 3. A large system prompt definition
 4. Anything else that will fill up the environment

 For example, this error can occur if several Microsoft languages have
 been set up on a system and their associated environment variables
 have been placed in the AUTOEXEC.BAT file.

 A SHELL statement can be placed in the CONFIG.SYS file to increase the
 size of the environment and eliminate the error.

 In MS-DOS Versions 3.20 and later, a typical shell statement is as
 follows:

    SHELL=C:\COMMAND.COM /p /e:512

 The default is 160 bytes. This example sets the environment to 512
 bytes. The size can be as large as 32768 bytes, but this is not
 recommended because it wastes memory if the space is not really
 needed.

 In MS-DOS Versions 3.00 and 3.10, a typical shell statement is as
 follows:

    SHELL=C:\COMMAND.COM /p /e:32

 The default size is 10 (160 bytes). Size is expressed in multiples of
 16 bytes. The above example sets the environment to 512 bytes
 (16 * 32). The size can't be greater than 64 (1024 bytes).


 590. F6099: INTEGER Overflow Error with Char Function

 Product Version(s): 5.00   | 5.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | buglist5.00
 Last Modified:  2-MAR-1990    ArticleIdent: Q59231

 The "F6099 run-time error - INTEGER overflow" may not be generated
 correctly when the /4Yb switch is used at compile time on code that
 contains a write statement and the char intrinsic function, in that
 order.

 Microsoft has confirmed this to be a problem in Version 5.00. We are
 researching this problem and will post new information here as it
 becomes available.

 The code below produces the F6099 run-time error when compiled with
 the /4Yb switch (extended error handling).

       character*1 jcha
       ic = 134
       write (*,*) ic
       jcha = char(ic - 68)
       end

 It gives the same error both in DOS and OS/2. The code compiles and
 runs without errors on previous versions of Microsoft FORTRAN.

 If the write statement is commented out, or if 76 is substituted for
 the expression "ic - 68", no error is produced.

 If the integer variable, ic, is initialized to a value of 127 or less,
 the error does not occur. Also, if the character variable, jcha, is
 typed as character*2 or greater, the error does not occur. Finally,
 the numeral 68 in the char function can be replaced with any integer
 greater than 0 and it will still generate the F6099 error at run time.


 591. Manually Patching the FORTRAN 5.00 8087 Control Word

 Product Version(s): 5.00
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist5.00
 Last Modified: 27-MAR-1990    ArticleIdent: Q59379

 Using the Microsoft FORTRAN 5.00 coprocessor or math emulation library
 on an Intel 8087 math coprocessor (not an 80287 or 80387 coprocessor)
 may give incorrect results for math operations. The symptoms of this
 problem are incorrect results, loss of decimal place precision, or
 unexpected zero results. In some cases the machine may lock or hang at
 run time. The problem is caused by incorrect initialization of the
 8087 control word.

 To properly diagnose the problem, link the program with the emulator
 library, and set the NO87 environment variable (described on Page 17
 of the "Microsoft FORTRAN Advanced Topics" Version 5.0 manual). The
 patch listed below is necessary if the program runs correctly without
 the coprocessor (using NO87), but does not execute properly when the
 8087 coprocessor is used. Note: It is also possible, in this case,
 that the coprocessor is bad or there is another conflict on the
 machine.

 The FORTRAN 5.00 8087 Control Word patch is available from Microsoft
 Product Support Services by calling (206) 454-2030. This patch is for
 the FORTRAN coprocessor and math emulation libraries and is for use
 with the 8087 coprocessor, not the 80287 or the 80387.

 It is also possible to patch the library manually using LIB.EXE
 and DEBUG.COM. This process is outlined below.

 The procedure to patch the library first uses the library manager
 LIB.EXE to extract the module 87EXIST.OBJ. The module is then loaded
 into DEBUG, which is used to patch 7 bytes in the module. Finally,
 LIB.EXE is used to put the module back into the FORTRAN library.
 Familiarity with DEBUG is highly recommended for carrying out this
 procedure.

 To patch the FORTRAN 5.00 coprocessor library for use with the 8087,
 follow these steps:

 1. Make sure that the DOS directory and FORTRAN BIN directory are
    listed in the PATH.

 2. Change to the FORTRAN LIB directory.

 3. Type the following keystrokes verbatim (substituting the name of
    the FORTRAN coprocessor or emulator library you are using for
    LLIBFOR7.LIB below):

       LIB LLIBFOR7.LIB-*87EXIST; <ENTER>

       DEBUG 87EXIST.OBJ <ENTER>

       E 12DD:01E9 B9 1E 00 E2 FE DB E3 <ENTER>

       W <ENTER>

       Q <ENTER>

       LIB LLIBFOR7.LIB+87EXIST; <ENTER>

 The library is now patched and can be used normally.

 Notes
 -----

 1. If patching the math emulation library, use the library name
    LLIBFORE.LIB instead of LLIBFOR7.LIB.

 2. If, during any operation, something goes wrong and control is not
    returned to the DOS or DEBUG prompt, start over from the beginning.
    LIB.EXE will make a backup copy of the library when invoked, naming
    it with the .BAK extension. Simply rename the library to the .LIB
    extension and start over.

 3. OS/2 USERS: To be able to invoke DEBUG, you will have to boot to a
    version of DOS.


 592. L2029: Unresolved External ___aDBswpchk with GRAPHICS.LIB

 Product Version(s): 5.00
 Operating System:   OS/2
 Flags: ENDUSER | S_LINK
 Last Modified: 27-MAR-1990    ArticleIdent: Q59421

 Linking with GRAPHICS.LIB in OS/2 may give the following error
 message:

    d:\lib\GRAPHICS.LIB(..\gr\qeswap.asm) : error L2029 :
      '___aDBswpchk' : unresolved external

 This is because GRAPHICS.LIB is designed for DOS and is being linked
 with a protected-mode FORTRAN library, which does not include the
 external references required by GRAPHICS.LIB.

 Link with the real-mode library to correct the problem.

 For example, the following sample programs included with FORTRAN
 Version 5.00 produce this error if linked under OS/2:

    MAGNIFY.FOR
    COLOR.FOR
    TEXT.FOR
    ANIMATE.FOR
    EGA.FOR


 593. FORTRAN 5.00 Loop Optimization, Subroutine, and Array Problem

 Product Version(s): 5.00   | 5.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | buglist5.00 bad bogus wrong invalid
 Last Modified: 27-MAR-1990    ArticleIdent: Q59422

 In FORTRAN Version 5.00, the loop optimizer does not correctly
 optimize the subroutine MOVE in the code below, producing incorrect
 output.

 /Od or /Odt takes care of the problem.

 Microsoft has confirmed this to be a problem in Version 5.00. We are
 researching this problem and will post new information here as it
 becomes available.

       integer*2 buf(20)
       do 10 i=1,10
 10    buf(i) = 9

       call move(10,buf(11),buf)

       write(*,'(10(i8))') (buf(i),i=1,20)
       end

       Subroutine move(npts, y1, y2)
       integer*2 y1(*), y2(*)
       do 10 i=1,npts
         y2(i) = y1(i)
 10    continue
       return
       end

 The following is the correct output:

     0     0     0     0     0     0     0     0     0     0
     0     0     0     0     0     0     0     0     0     0

 The following is the incorrect output:

     0     0     0     0 21325 21024 28277 21549 28009  8293
     0     0     0     0     0     0     0     0     0     0


 594. Using the SYSTEM and SPAWN Functions with FORTRAN

 Product Version(s): 4.00 4.01 4.10 5.00 | 4.10 5.00
 Operating System:   MS-DOS              | OS/2
 Flags: ENDUSER | 4.xx
 Last Modified: 27-MAR-1990    ArticleIdent: Q59602

 The DEMOEXEC.FOR sample program that is included with the Microsoft
 FORTRAN Optimizing Compiler demonstrates how to use DOS commands and
 execute programs from within a FORTRAN program.

 The SYSTEM command allows a FORTRAN program to execute DOS commands.
 For instance, a program may clear the screen by using the DOS CLS
 command.

 The SPAWN command allows a FORTRAN program to spawn -- or chain -- a
 program from itself. The FORTRAN program remains in memory while the
 spawned program is executed. Control is returned to the spawning
 FORTRAN program when the spawned program completes.

 For more information on the SYSTEM and SPAWN functions, please refer
 to the DEMOEXEC.FOR program included with your Microsoft FORTRAN
 Optimizing Compiler, or to Pages 87-88 in the "Microsoft FORTRAN
 Advanced Topics" manual for Version 5.00.


 595. Using Backslashes with the FORTRAN SYSTEM and SPAWN Functions

 Product Version(s): 4.00 4.01 4.10 5.00 | 4.10 5.00
 Operating System:   MS-DOS              | OS/2
 Flags: ENDUSER | 4.xx
 Last Modified: 27-MAR-1990    ArticleIdent: Q59603

 Care should be taken when using backslash (\) characters in strings
 passed to the SYSTEM and SPAWN functions. The SYSTEM and SPAWN
 functions are actually C routines. In C, the backslash character is
 used to denote an editing descriptor, somewhat similar to the way the
 I, F, X, etc., editing descriptors are used in the FORTRAN FORMAT
 statement. The following sample SYSTEM call incorrectly uses the
 backslash character:

    I = SYSTEM('dir c:\fortran\src\*.for'C)

 The C function associated with the FORTRAN SYSTEM function will
 interpret the backslashes as editing descriptors. In C, if you want to
 print out a backslash you must follow the first backslash with
 another; this tells C to temporarily ignore the backslash as an
 editing descriptor. The following line demonstrates how to properly
 use the backslash character in the SYSTEM and SPAWN functions:

    I = SYSTEM('dir c:\\fortran\\src\\*.for'C)

 For more information on the SYSTEM and SPAWN functions, please refer
 to the DEMOEXEC.FOR program included with the Microsoft FORTRAN
 Optimizing Compiler, or Pages 87-88 of the "Microsoft FORTRAN Advanced
 Topics" manual for Version 5.00.


 596. Speeding Up the Coprocessor Library with FORTRAN 5.00

 Product Version(s): 5.00   | 5.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | /FPi87 docerr
 Last Modified: 18-JUL-1990    ArticleIdent: Q59604

 Pages 9-10 of the "Microsoft FORTRAN Advanced Topics" version 5.0
 manual and Page 323 of the "Microsoft FORTRAN Reference" version 5.0
 manual include Assembly source code that, when assembled and linked
 with a FORTRAN program and the coprocessor library, is supposed to
 increase the speed with which coprocessor functions are executed. The
 code is designed to create true inline coprocessor instructions.

 However, the code, as it appears on the above pages, contains several
 errors and will not assemble correctly. Minor changes can be made so
 that no Assembly or link errors occur, but the code will still not
 speed up calls to the coprocessor. The following code is a corrected
 version of the code in the advanced topics and reference manuals.
 Through informal testing, this corrected code has been found to speed
 up inline coprocessor code by as much as 2 to 3 percent.

 Please note that different switches must be used with the following
 code, depending on whether or not the coprocessor is an 8087.

      page ,132
      title     rmfixups
 ;
 ;rmfixups.asm -
 ;
 ;   Copyright (c) 1988-1990, Microsoft Corporation.
 ;         All Rights Reserved.
 ;
 ;Purpose:
 ;
 ;   To remove floating point fixups, create rmfixups.obj with:
 ;
 ;      masm -Mx rmfixups.asm,rmfixups.obj;
 ;
 ;   Then, link your .OBJs with rmfixups.obj and use the /noe link
 ;   switch. This .EXE will only run correctly on a machine with an
 ;   80x87 (or 80486).
 ;
 ;
 ;   To remove floating point fixups and fwait instructions that are
 ;   only needed with an 8087, create rmfwaits.obj with:
 ;
 ;      masm -Mx -DRM_FWAITS rmfixups.asm,rmfwaits.obj;
 ;
 ;   Then, link your .OBJs with rmfwaits.obj and use the /noe link
 ;   switch. This .EXE will only run correctly on a machine with an
 ;   80287, 80387, or 80486.
 ;
 ;*********************************************************************

 public FIWRQQ,FIERQQ,FIDRQQ,FISRQQ,FJSRQQ,FIARQQ,FJARQQ,FICRQQ,FJCRQQ

 ifdef  RM_FWAITS

     bFWAIT  equ     09bh
     bNOP    equ     090h

     FIDRQQ  equ     (bNOP - bFWAIT)
     FIERQQ  equ     (bNOP - bFWAIT)
     FIWRQQ  equ     0

     FIARQQ  equ     (bNOP - bFWAIT)
     FJARQQ  equ     0
     FISRQQ  equ     (bNOP - bFWAIT)
     FJSRQQ  equ     0
     FICRQQ  equ     (bNOP - bFWAIT)
     FJCRQQ  equ     0

 else ;not RM_FWAITS

     FIDRQQ  EQU     0
     FIERQQ  EQU     0
     FIWRQQ  EQU     0

     FIARQQ  EQU     0
     FJARQQ  EQU     0
     FISRQQ  EQU     0
     FJSRQQ  EQU     0
     FICRQQ  EQU     0
     FJCRQQ  EQU     0

 endif     ;not RM_FWAITS

 extrn     __fpmath:far
 extrn     __fptaskdata:far
 extrn     __fpsignal:far

 CDATA     segment word common 'DATA'
      dw   0
      dd   __fpmath
      dd   __fptaskdata
      dd   __fpsignal
 CDATA     ends

 end


 597. Multidimensional Array in Common Block Addressing Problem

 Product Version(s): 5.00   | 5.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | buglist5.00
 Last Modified: 27-MAR-1990    ArticleIdent: Q59605

 When accessing multidimensional arrays that are located within a
 common block, a protection violation may result at run time under
 OS/2, or incorrect results under MS-DOS.

 The following code illustrates the problem. At run time, this code
 generates a protection violation under OS/2:

       common /cbname/array1(5,5)

       integer*4 array1,array2(5,5)

       do 10 j = 1,5
       array1(i,j)=array1(i,j)+array2(i,j)
 10    CONTINUE
       end

 The above code results in various positions in the array being
 skipped when run under DOS.

 Microsoft is researching this problem and will post new information
 here as it becomes available.


 598. BLOCK DATA Routine, and FORTRAN and Library Files

 Product Version(s): 4.00 4.01 4.10 5.00 | 4.10 5.00
 Operating System:   MS-DOS              | OS/2
 Flags: ENDUSER | S_LINK
 Last Modified: 27-MAR-1990    ArticleIdent: Q59606

 BLOCK DATA may not initialize data in common blocks when the block
 data routine is placed in a library.

 This is because of the operation of the linker program. The linker
 program only moves modules from library files into the executable if
 they are required to resolve external references.

 If the BLOCK DATA routine is the only thing in a particular module
 within a library, it will never be called into the executable.

 A BLOCK DATA routine generates a common block with initialized data.
 Because a common block is declared in each location it is used, it is
 not treated as an unresolved external when the linker is linking with
 other object modules.

 To make this work properly, make sure that the module the BLOCK DATA
 routine is located in is loaded by the linker to resolve some other
 external reference. This can be done by having a piece of executable
 code in the same module and making sure that it is needed in any
 program that wants to use the initialized block data.

 File in Library
 ---------------

 C ******** BLOCK DATA statement at beginning of file ***

       BLOCK DATA foo
         integer*2   int1
         real*4      real1
         character*2 char1
         logical     log1
         common /test/ int1, real1, char1, log1
         data int1, real1, char1, log1 /1,4.0,'ZZ',.true./
       END

       subroutine foo2 ! this is here to fulfill unresolved external.
       end

 File in Object File
 -------------------

 C ******** Beginning of main program *******************

       PROGRAM block

       integer*2   int1
       real*4      real1
       character*2 char1
       logical     log1

       common /test/ int1, real1, char1, log1

       write (*,100) int1, real1, char1, log1
 100   format (1X, I1, 3X, F3.1, 3X, A2, 3X, L1)
       call foo2 ! this causes Unresolved external, requiring load from
                 ! the Library file.

       end


 599. FORTRAN Setup Causes SYS2090 Error

 Product Version(s): 4.00 4.01 4.10 5.00
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 27-MAR-1990    ArticleIdent: Q59735

 The system error SYS2090 during FORTRAN setup may be caused by:

 1. Either of the following:

    a. Using DOS Version 2.x or a Version 2.x COMMAND.COM with a
       different version of DOS

    b. Running bound programs under DOS 2.x (query on "SYS2090" for
       more information on this situation)

    Note: DOS 3.00 or later is required for FORTRAN 5.00.

 2. Interference from TSRs or network software

 3. A corrupt FORTRAN file


 600. Opening More Than 20 Files Under OS/2 with FORTRAN 5.00

 Product Version(s): 5.00
 Operating System:   OS/2
 Flags: ENDUSER | limit F6417 too many open files
 Last Modified: 24-JUL-1990    ArticleIdent: Q60046

 To increase the maximum number of open files with Microsoft FORTRAN
 5.00 under OS/2, follow the steps below. This procedure requires the
 use of Microsoft Macro Assembler Version 5.10 or later.

 The following information is also found on Pages 405-407 in the
 "Microsoft FORTRAN Reference" Version 5.0 manual.

 Note: The file CRT0DAT.ASM must be assembled using the /Dmem_l switch.
 This is not stated in the manual.

 1. Edit the file CRT0DAT.ASM found on the Source Code disk in the
    \STARTUP\OS2 directory.

    Change the following line

       _NFILE_=20

    to the following:

       _NFILE_=xx (replace xx with the number of files)

    Delete the comment mark (;) from the following line in CRT0DAT.ASM:

       ;  extrn DOSSETMAXFH:far

    You also should delete the comment marks (;) from the following
    lines in CRT0DAT.ASM:

       ;  mov ax,_NFILE_
       ;  push ax
       ;  call DOSSETMAXFH

    After you delete the comment marks, the lines should read as
    follows:

       mov ax,_NFILE_
       push ax
       call DOSSETMAXFH

 2. Edit the UNIT.ASM file on the Source Code disk in the \STARTUP
    directory. Change the following line

       _NFILE_   equ 20

    to the following:

       _NFILE_equ xx  (same as in the CRT0DAT.ASM file)

 3. Assemble (using Microsoft Macro Assembler Version 5.10) the
    UNIT.ASM and CRT0DAT.ASM files with the following lines [note that
    in mem_l, the last character is the lowercase letter "l", not the
    number 1 (one)]:

       MASM /Dmem_l CRT0DAT.ASM

       MASM UNIT.ASM

 4. Link the .OBJ files with the FORTRAN .OBJ file as in the following
    statement (where FOO.OBJ is your FORTRAN object code):

       LINK /NOE FOO.OBJ + UNIT.OBJ + CRT0DAT.OBJ;


 601. Accessing Mixed-Language, External Variables in FORTRAN

 Product Version(s): 4.10 5.00 | 4.10 5.00
 Operating System:   MS-DOS    | OS/2
 Flags: ENDUSER | S_C
 Last Modified: 30-MAR-1990    ArticleIdent: Q60076

 The following is a sample C and FORTRAN mixed-language program
 demonstrating how to access external variables from within Microsoft
 FORTRAN.

 FORTRAN Code
 ------------

       SUBROUTINE ASSIGN
       INTEGER*2 X [EXTERN, ALIAS:'_extrn']

       X = 2
       END

 C Code
 ------

 #include <stdio.h>

 extern void fortran assign(void);
 int extrn;

 main()
 {
     extrn = 5;
     printf("Before call to FORTRAN:  %d\n",extrn);
     assign();
     printf(" After call to FORTRAN:  %d\n",extrn);
 }

 To use global variables exported from another language in FORTRAN, the
 EXTERN attribute must be used. EXTERN tells the FORTRAN compiler that
 the variable is not local to the FORTRAN subroutine or function.
 Variables declared EXTERN will instead be resolved by the linker. You
 can use the ALIAS attribute to assign a different name to the imported
 variable; in this example, it is required because the underscore
 prepended by the C compiler is invalid in the FORTRAN naming
 convention.

 No modifications should be necessary for the exporting module to allow
 FORTRAN to import the global variable(s).


 602. $DEBUG and /4Yb May Increase Executable File Size

 Product Version(s): 5.00   | 5.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | large big
 Last Modified: 30-MAR-1990    ArticleIdent: Q60077

 If an executable file size, or the load size of the executable, seems
 to be larger with Microsoft FORTRAN Version 5.0 than it was when
 compiling under a previous version of FORTRAN, it could be due to the
 use of the $DEBUG metacommand or /4Yb switch.

 Both /4Yb and $DEBUG include extended error handling information in
 the .EXE file. Reports from customers and some informal testing show
 that with FORTRAN 5.00, there may be an executable file size increase
 of anywhere from 5 to 28 percent when either /4Yb or $DEBUG are used.
 The load size of the executable also increases at about the same
 percentage. Also, it seems the larger and more complicated the code,
 the percentage that the .EXE file increases is higher. Previous
 versions of FORTRAN (Version 4.00, 4.10, etc.) do not show as large an
 increase, although the increase may be anywhere from 3 to 19 percent.


 603. Using the NEAR Attribute with Common Blocks in FORTRAN

 Product Version(s): 5.00   | 5.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified: 30-MAR-1990    ArticleIdent: Q60079

 On Page 34 of the "Microsoft FORTRAN Advanced Topics" guide is a
 description of using the NEAR attribute in conjunction with common
 blocks. In Microsoft FORTRAN, common blocks are by default put in
 their own segment. This saves space in the default data segment
 (DGROUP). The drawback to this method is that data in common blocks
 must be accessed through far pointers; code is therefore larger and
 slower. Use of the NEAR attribute with small, frequently used common
 blocks will speed up execution of the program and reduce code size.
 The only requirement is that there must be space in the default data
 segment.

 When using the NEAR attribute with common blocks, the data in each
 common block may appear to remain in its own segment rather than in
 DGROUP if a source listing (/Fs) is used. This may be confusing when
 there is obviously enough space in the default data segment. After
 examining an object listing (/Fl) or a map listing (/Fm), it becomes
 clear that the segments containing the NEAR common blocks are
 concatenated into the default data segment.

 The following code is a sample program using the NEAR attribute to put
 common blocks in the default data segment:

       integer*4 a,b,c
       common    /c1 [near]/ a,c
       common    /c2 [near]/ b
       end

 The source listing describes each common block:

    Global Symbols
    Name                      Class   Type              Size   Offset
    C1. . . . . . . . . . . . common  ***                  8    0000
    C2. . . . . . . . . . . . common  ***                  4    0000
    main. . . . . . . . . . . FSUBRT  ***                ***    0000

 The map file demonstrates that each common block is included in
 DGROUP. Note that the segment address of each common block is 005Dh,
 which is the same as DGROUP. The map file contains the following:

  Start  Stop   Length Name                   Class
  00710H 00713H 00004H C2$A                   $C2
  00720H 00727H 00008H C1$A                   $C1

  Origin   Group
  005D:0   DGROUP

   Address         Publics by Name
  005D:0130       C1
  005D:0120       C2

   Address         Publics by Value
  005D:0120       C2
  005D:0130       C1

 The object listing includes a description of the grouping of all the
 segments, including the common blocks, into DGROUP:

      NAME    common

 C2$A SEGMENT  PARA COMMON '$C2'
 C2$A ENDS
 C1$A SEGMENT  PARA COMMON '$C1'
 C1$A ENDS
 DGROUP    GROUP     CONST, _BSS, _DATA, C2$A, C1$A
      ASSUME  CS: COMMON_TEXT, DS: DGROUP, SS: DGROUP, ES: DGROUP


 604. FORTRAN 5.00 .FON Files Identical to Windows .FON Files

 Product Version(s): 5.00
 Operating System:   MS-DOS
 Flags: ENDUSER | docerr
 Last Modified: 30-MAR-1990    ArticleIdent: Q60097

 On Page 187 in the "Microsoft FORTRAN Advanced Topics" Version 5.0
 manual, it states that FORTRAN's .FON font files are identical to the
 .FNT font files used in Microsoft Windows. This is incorrect.

 Instead, the manual should read as follows:

    FORTRAN's .FON files are identical to the .FON files used in the
    Microsoft Windows operating environment.

 All four occurrences of ".FNT" on that page should be changed to
 ".FON."

 Brief testing shows that the Windows .FON files will work with
 Microsoft FORTRAN Version 5.00. (Note: Windows Version 2.11 .FON files
 were used for this test.)


 605. FORTRAN 5.00 Differences from Previous Versions

 Product Version(s): 3.20 3.30 3.31 4.00 4.01 4.10 5.00 | 4.10 5.00
 Operating System:   MS-DOS                             | OS/2
 Flags: ENDUSER | 3.xx 4.xx 5.xx
 Last Modified:  2-APR-1990    ArticleIdent: Q60151

 For information on what has changed in Microsoft FORTRAN as the
 language has evolved from Version 3.20 to 5.00, see Appendix B (Pages
 373-400) of the "Microsoft FORTRAN Reference" Version 5.0 manual.

 Information on changes is ordered as follows:

 1. Changes from Version 4.10 to 5.00 (Pages 373-377)

 2. Changes from Version 4.00 to 4.10 (Pages 377-379)

 3. Changes from Versions 3.20 and 3.30 to 4.00 (Pages 379-388)


 606. Improper Array Declaration May Cause Computer to Hang

 Product Version(s): 5.00   | 5.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | buglist5.00
 Last Modified: 23-MAY-1990    ArticleIdent: Q61530

 Microsoft FORTRAN permits operations on full arrays that would
 normally only work with single arguments (scalars); these operations
 are called array expressions. In cases where an array is declared
 improperly, an array expression involving that array may cause the
 computer to hang at run time.

 The following is a simple program that demonstrates this problem:

       integer*4 array(4:1)    ! Improper array declaration
       array = 0               ! Array expression
       end

 The problem with this program is that the array indexes are declared
 in reverse order. The FORTRAN compiler does not generate any error
 messages, but when run under DOS the program will cause the computer
 to hang; under OS/2 CTRL+C will terminate the program.

 Microsoft is currently researching this problem and will post new
 information here as it becomes available.


 607. Repeated Edit Descriptors Do Not Work with Implied-DO Loop

 Product Version(s): 5.00   | 5.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | buglist5.00
 Last Modified:  8-JUN-1990    ArticleIdent: Q61533

 Repeated edit descriptors in FORMAT statements used with implied-DO
 loops do not work properly. In this case, Microsoft FORTRAN version
 5.00 does not reset the FORMAT statement properly. On the second cycle
 through the FORMAT statement, the variables to be output have no edit
 descriptors associated with them; thus, a run-time error F6207 will
 result.

 The following program demonstrates the problem:

       integer*2 j
       real*4   x(4),y(4)

       write (*,10) (j,x(j),y(j),j=1,4)
  10   format (2x,i2,2(2x,f6.1))

 C  No errors are generated if the following line is used in place of
 C  the above FORMAT statement
 C 10  format (2x,i2,2x,f6.1,2x,f6.1)
       end

 The output is as follows:

   1      .0      .0
 run-time error F6207: WRITE(CON)
 - I edit descriptor expected for INTEGER

 The output should be the following:

   1      .0      .0
   2      .0      .0
   3      .0      .0
   4      .0      .0

 Microsoft is currently researching this problem and will post new
 information here as it becomes available.


 608. L2029 and L2025 with Pascal 4.00 and FORTRAN 4.10 or 5.00

 Product Version(s): 4.10 5.00 | 4.10 5.00
 Operating System:   MS-DOS    | OS/2
 Flags: ENDUSER | buglist4.10 buglist5.00 S_PASCAL S_LINK
 Last Modified: 23-MAY-1990    ArticleIdent: Q61536

 When using real numbers and mathematical calculations between
 Microsoft Pascal version 4.00 and Microsoft FORTRAN version 4.10 or
 5.00, the following error messages may be generated, depending on the
 order of the libraries at link time:

    error L2029: Unresolved externals

    error L2025: symbol defined more than once

 The code should link without errors if the FORTRAN library is placed
 first on the link line.

 With FORTRAN 4.00 or 4.01, the code functions correctly.

 Microsoft is currently researching this problem and will post new
 information here as it becomes available.

 The following code generates the linker error messages listed below:

 PMIX.PAS
 --------

 program pmix(input,output);

 procedure fort(vars xold, xdata: real); extern;

 var xdata, xold: real;
 begin
   xold:=1.0;
   fort(xold, xdata);
   writeln('xdata = ',xdata);
 end.

 FMIX.FOR
 --------

       subroutine fort(xold,xdata)
       real xold, xdata
       integer*4 idec
       idec=3
       xdata=xold/10.**idec
       return
       end

 With the FORTRAN library first:

    link pmix fmix /nod /noe,,,llibfer libpaser;

    LINK : error L2029: Unresolved externals:

    __positive in file(s):
     LLIBFER.LIB(\mrt\c\fltused.ASM)
    __cftoe in file(s):
     LLIBFER.LIB(\mrt\c\fltused.ASM)
    __cftof in file(s):
     LLIBFER.LIB(\mrt\c\fltused.ASM)
    __cftog in file(s):
     LLIBFER.LIB(\mrt\c\fltused.ASM)
    __cropzeros in file(s):
     LLIBFER.LIB(\mrt\c\fltused.ASM)
    __cfltcvt in file(s):
     LLIBFER.LIB(\mrt\c\fltused.ASM)
    __forcdecpt in file(s):
     LLIBFER.LIB(\mrt\c\fltused.ASM)
    __fassign in file(s):
     LLIBFER.LIB(\mrt\c\fltused.ASM)

    There were 8 errors detected

 With the Pascal library first:

    link pmix fmix /nod /noe,,,libpaser llibfer;

    LLIBFER.LIB(dos\crt0.asm) : error L2025: __aexit_rtn :
    symbol defined more than once
     pos: 2B6F5 Record type: 7F04
    LLIBFER.LIB(dos\crt0.asm) : error L2025: __abrkp : symbol
    defined more than once
     pos: 2B72C Record type: 7F04
    LLIBFER.LIB(dos\crt0.asm) : error L2025: __abrktb : symbol
    defined more than once
     pos: 2B738 Record type: 7F04
    LLIBFER.LIB(dos\crt0.asm) : error L2025: __asizds : symbol
    defined more than once
     pos: 2B744 Record type: 7F04
    LLIBFER.LIB(dos\crt0.asm) : error L2025: __astart : symbol
    defined more than once
     pos: 2B756 Record type: 7F04
    LLIBFER.LIB(dos\crt0.asm) : error L2025: __atopsp : symbol
    defined more than once
     pos: 2B768 Record type: 7F04
    LLIBFER.LIB(dos\crt0.asm) : error L2025: __abrktbe : symbol
    defined more than once
     pos: 2B775 Record type: 7F04
    LLIBFER.LIB(dos\crt0.asm) : error L2025: __cintDIV : symbol
    defined more than once
     pos: 2B788 Record type: 7F04
    LLIBFER.LIB(dos\crt0.asm) : error L2025: __amsg_exit :
    symbol defined more than once
     pos: 2B7E4 Record type: 7F04

    There were 9 errors detected

 With FORTRAN 4.00 or 4.01, the above code generates the following
 error message at link time, but it creates an executable and seems to
 function correctly if the Pascal library is placed first at link time:

 LLIBFORE(dbgmsg) : error L2025 : __FF_MSGBANNER : symbol defined more
 than once

 The above symbol can be removed from the FORTRAN library to eliminate
 the error message.


 609. Error in Example on Page 39 of 5.0 Reference Guide

 Product Version(s): 5.00   | 5.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | docerr
 Last Modified: 23-MAY-1990    ArticleIdent: Q61778

 The example code on Page 39 of the "Microsoft FORTRAN Quick Reference
 Guide" for Microsoft FORTRAN version 5.0 is incorrect. The second
 example of logical expressions is not equivalent as the manual states.

 The text in the manual reads as follows:

    C  The following two statements are equivalent:

       go =  .NOT. a  .OR. b  .AND. c
       go =  ((.NOT. a) .OR. b) .AND. c

 These statements are not equivalent. One possible equivalent
 combination would be as follows:

    go = .NOT. a  .OR. b  .AND. c
    go = (.NOT. a) .OR. (b .AND. c)


 610. Line-Continuation Error in the $FREEFORM Sample Program

 Product Version(s): 5.00   | 5.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | docerr
 Last Modified: 23-MAY-1990    ArticleIdent: Q61789

 There is a documentation error on Page 296 of the "Microsoft FORTRAN
 Reference" for version 5.0 in the sample program under the $FREEFORM
 metacommand. The error is on the 300 FORMAT... line, which is the
 second to the last line in the sample program.

 The $FREEFORM metacommand states that if the last nonblank or
 noncomment character of a line is a minus (-) sign, it is interpreted
 as a line continuation and discarded. However, the sample program uses
 the conventional character in column 6 for the line continuation and
 does not have the minus (-) sign to indicate a line continuation.

 When using the $FREEFORM metacommand, you must use the minus (-) sign
 to indicate a line continuation.

 If you compile the sample program, it causes the following errors:

    freeform.for(32) : warning F4988: unexpected end of format
    freeform.for(33) : error F2115: syntax error

 The following is the corrected example:

 $FREEFORM

 "The sine of the number x is calculated using a power
 series.
 "Successive terms are calculated until one is less than epsi.

     REAL x, epsi, z, sine, next
     INTEGER i
     epsi = 0.0001

     WRITE (*,100)

 100 FORMAT ( 1X, 'ENTER x: ' \ )

     READ (*,'(F10.5)') x

     z = AMOD( x, 6.2831853 )
     sine = z
     i = 4
     next = -z * z * z / 6.0

 200 IF ( ABS( next ) .GE. epsi ) THEN

      sine = sine + next
      next = -next * z * z / (i * (i + 1))
      i = i + 2
      GOTO 200

     END IF

     WRITE (*,300) x, sine

 300 FORMAT ( 1X, 'THE SINE OF ',F10.5, - ! This is the correct
           ' = ',F12.10 )                 ! line continuation
                                          ! for $FREEFORM

 END


 611. SETFILLMASK Graphics Routine and Integer Range Error F2367

 Product Version(s): 5.00
 Operating System:   MS-DOS
 Flags: ENDUSER | sine fill
 Last Modified:  9-JUL-1990    ArticleIdent: Q62476

 If you use the SETFILLMASK graphics routine in Microsoft FORTRAN, you
 shouldn't use the $DEBUG metacommand in the source code or compile
 using the /4Yb compiler switch. The array used by the routine is
 declared as INTEGER*1 and if you have any values greater than 127 in
 the array, it produces an "F2367 Integer range error" at compile time.

 The SINE.FOR and FILL.FOR sample programs which are included on the
 Source Code Disk in the Samples subdirectory will produce the above
 error when either /4Yb or $DEBUG are used.

 SETFILLMASK uses an 8 x 8 bit array for the fill-mask design. The
 array must be initialized as INTEGER*1, which has a range of -128 to
 127. The values of the bit array must be able to range from 0 to 255
 in decimal and 00000000 to 11111111 in binary to get every combination
 of fill patterns. This, however, can exceed the range of the INTEGER*1
 array.

 Without using the debug options, the program compiles and works
 correctly, but if you add one of the above debug options and have a
 value in the mask array that is larger that 127, you receive the
 following compiler error:

    name.for(23) : error F2367: value 129 : INTEGER : range error

 The debug option performs range checking of variables. For example, if
 an INTEGER*1 variable exceeds 127 the compiler produces an error.

 If you compile the following example with the /4Yb compiler switch, the
 following errors are produced:

    fill.for
    fill.for(23) : error F2367: value 129 : INTEGER : range error
    fill.for(23) : error F2367: value 145 : INTEGER : range error

 The following is an example using the SETFILLMASK graphics routine:

 C Won't compile with $DEBUG metacommand or with the /4Yb
 C compiler switch because of the two elements in the array
 C mask that are larger than 127.

       INCLUDE 'FGRAPH.FI'
       INCLUDE 'FGRAPH.FD'

       INTEGER*2 dummy_2    ! Variables for Function Return
       INTEGER*4 dummy_4    !    Values

       INTEGER*1 mask(8)    ! Integer*1 has range of -128 to 127
                            !    Largest mask value can be
                            !    11111111b or 255d

 C               Binary      Decimal
 C              --------     -------
       DATA mask / 2# 00000000 ,   !  0d
      +            2# 00111100 ,   !  60d
      +            2# 01000010 ,   !  66d
      +            2# 10000001 ,   !  129d ! Error with /4Yb
      +            2# 10010001 ,   !  145d ! Error with /$Yb
      +            2# 01001010 ,   !  74d
      +            2# 00111100 ,   !  60d
      +            2# 00000011  /  !  3d

       dummy_2 = setvideomode( $VRES16COLOR )  ! Set 16 Color VGA Mode
       dummy_4 = setbkcolor( $BLUE )     !BLUE ! Set Background Color

       CALL clearscreen( $GCLEARSCREEN )

       dummy_2 = setcolor( 15 )          !WHITE

       CALL setfillmask(mask)

       dummy_s = rectangle( $GBORDER, 100,100,500,300 ) ! Border

       dummy_2 = rectangle( $GFILLINTERIOR, 100,100,500,300 ) ! Fill
                                                              ! with
       PAUSE                                                  ! Mask

       dummy_2 = setvideomode( $DEFAULTMODE )  ! Reset Video Mode

       END


 612. GetTextWindow Not Listed in Include Files and Does Not Work

 Product Version(s): 5.00   | 5.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | buglist5.00
 Last Modified:  6-JUN-1990    ArticleIdent: Q62484

 The GetTextWindow subroutine listed in the "Additional Graphics
 Routines" section of the README.DOC file on the Setup Disk does not
 work correctly. First, the corresponding routine in the GRAPHICS.LIB
 library does not work correctly. In addition, the include files that
 are needed with the graphics routines, FGRAPH.FI and FGRAPH.FD, have
 no entry for this subroutine.

 The first problem has no solution. The second problem can be corrected
 by adding the following information to the corresponding include files
 as shown below.

 Add the following to the FGRAPH.FI include file:

     INTERFACE TO SUBROUTINE
    1 gettextwindow[FAR,C,ALIAS:"__gettextwindow"]
    1 (r1,c1,r2,c2)
     INTEGER*2 r1
     INTEGER*2 c1
     INTEGER*2 r2
     INTEGER*2 c2
     END

 Add the following to the FGRAPH.FD include file:

    EXTERNAL gettextwindow

 Note: The GetTextWindow subroutine is not listed in the "Graphics
 Library Routines" chapter of the "Microsoft FORTRAN Advanced Topics"
 manual.

 The GetTextWindow subroutine gets the boundaries of the current text
 window and is included in the GRAPHICS.LIB library. However, after
 adding the information above to the include files, the GetTextWindow
 subroutine does not work correctly. The subroutine returns zeros for the
 coordinates of the window regardless of the coordinates the window
 actually has.

 Also, depending on the hardware/software configuration, the machine
 may hang or a "run-time error R6003: integer divide by 0" may occur
 when executing the program. An example of using the subroutine is as
 follows:

 c
 c Compile command line: fl /FPi test.for graphics.lib /link /NOI
 c
       INCLUDE 'FGRAPH.FI'
       INCLUDE 'FGRAPH.FD'

       INTEGER x1,y1,x2,y2

       call settextwindow(10,10,30,20)
       call gettextwindow(x1,y1,x2,y2)
 c
 c Returns zeros for all four values
 c
       write (*,*) x1,y1
       write (*,*) x2,y2

       END

 Microsoft has confirmed this to be a problem in FORTRAN version 5.00.
 We are researching this problem and will post new information here as
 it becomes available.


 613. PIE Declaration in Manual Is Incorrect

 Product Version(s): 5.00
 Operating System:   MS-DOS
 Flags: ENDUSER | docerr
 Last Modified:  6-JUN-1990    ArticleIdent: Q62533

 There is a documentation error in the declaration of the PIE function
 on Page 233 of the "Microsoft FORTRAN Advanced Topics" manual for
 version 5.00.

 If the INTERFACE statement in the manual is used, an error "L2029 :
 '__f_pie' : unresolved external" occurs. The INTERFACE statement in
 the FGRAPH.FI include file contains the correct information.

 The incorrect line appears as follows:

       INTEGER*2 pie[FAR,C,ALIAS:"__f_pie"]

    "__f_pie" should be changed to "__pie" as follows:

       INTEGER*2 pie_w[FAR,C,ALIAS:"__pie"]

 The FIGURE.FOR sample program that is included with FORTRAN version
 5.00 illustrates the use of the PIE function.


 614. PIE_W Declaration in Manual Is Incorrect

 Product Version(s): 5.00
 Operating System:   MS-DOS
 Flags: ENDUSER | docerr
 Last Modified:  6-JUN-1990    ArticleIdent: Q62534

 There is a documentation error in the declaration of the PIE_W
 function on Page 233 of the "Microsoft FORTRAN Advanced Topics" manual
 for version 5.00.

 The incorrect line appears as follows:

    INTEGER*2 pie[FAR,C,ALIAS:"__f_pie_w"]

    "pie" should be changed to "pie_w" as follows:

    INTEGER*2 pie_w[FAR,C,ALIAS:"__f_pie_w"]


 615. Incorrect RGB Line in Manual; "9" Should Be "g"

 Product Version(s): 5.00   | 5.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | docerr
 Last Modified:  6-JUN-1990    ArticleIdent: Q62535

 There is a documentation error on Page 163 of the "Microsoft FORTRAN
 Advanced Topics" manual for version 5.00.

 The incorrect line appears as follows:

    RGB (r,g,b) = (#3f3f3f.AND.(ISHFT(b,16).OR.ISHFT(9,8).OR.r))

 The "9" should be changed to a "g" as follows:

    RGB (r,g,b) = (#3f3f3f.AND.(ISHFT(b,16).OR.ISHFT(g,8).OR.r))
                                                     |
                                        correction --|


 616. Example Using C or Assembly to Scroll Text for FORTRAN

 Product Version(s): 5.00
 Operating System:   MS-DOS
 Flags: ENDUSER | mixed language S_C H_MASM
 Last Modified: 19-JUN-1990    ArticleIdent: Q62885

 With an OUTTEXT call, it is not possible to embed CR/LF characters to
 enforce scrolling of text on the screen. To scroll the text, an
 assembler or C routine may be used as follows:

 1. Use SETTEXTPOSITION to position the cursor on the screen.

 2. Use OUTTEXT to display the output at that position.

 3. Call an Assembly or C routine to scroll the screen by one line.

 4. Return to step 1 above, positioning the cursor at the same location
    on the screen.

 The following code sample illustrates the use of the assembly routine:

        interface to subroutine scroll_line()
        end
        include 'fgraph.fi'
        include 'fgraph.fd'
        record/rccoord/curpos
 c
        call settextposition (10,20,curpos)
        call outtext('Hello1')
 c
        call scroll_line()
 c
        call settextposition (10,20,curpos)
        call outtext ('Hello2')
        end

 The following is the code segment of the assembly module:

 .model large,fortran

 .code

 scroll_line proc far
      push bp
      mov bp, sp
      mov ah,6          ;function 6H
      mov al,1          ;number of lines to scroll
      mov ch,0          ;row of top left corner
      mov cl,0          ;col of top left corner
      mov dh,24         ;row of bottom right corner
      mov dl,79         ;col of bottom right corner
      mov bh,7          ;attribute of line
      int 10h           ;interrupt 10h
      pop bp
      ret
 scroll_line endp
      end

 To use the C subroutine, only the interface statement of the FORTRAN
 module should be modified to read as follows:

        interface to subroutine scroll_line [FAR,C] ()
        end

 The following is the code segment of the C module:

 #include <stdio.h>
 #include <dos.h>

 union REGS reg;

 void scroll_line()
 {

 /*
  *  The registers have the same significance as those in
  *  the assembly-language routine above.
  */

   reg.h.ah = 6;     // function 6H
   reg.h.al = 1;     // number of lines to scroll
   reg.h.bh = 0x7;   // attribute of line
   reg.h.ch = 0;     // row of top left corner
   reg.h.cl = 0;     // column of top left corner
   reg.h.dh = 24;    // row of bottom right corner
   reg.h.dl = 79;    // row of top right corner

   int86(0x10, &reg, &reg);
   return;
 }

 The following is the MAKE file when the assembly module subroutine is
 used:

 all=1.obj 2.obj

 update: 1.for
     fl /Zi /c 1.for

 update: 2.asm
     masm /Zi 2.asm;

 update: $(all)
 link /co $(all),,,/nod graphics llibfer;

 The following is the MAKE file when the C module subroutine is used:

 all=1.obj 2.obj

 update: 1.for
     fl /Zi /c 1.for

 update: 2.c
     cl /AL /Zi /c 2.c

 update: $(all)
     link $(all)/co,,,/nod /noe graphics llibfer llibcer;


 617. FORTRAN 5.00 and C 6.00 Character String and Integer Array

 Product Version(s): 5.00   | 5.00
 Operating System:   MS-DOS | OS/2
 Flags: enduser |
 Last Modified:  6-JUL-1990    ArticleIdent: Q63308

 The following code is designed to show passing arrays and character
 strings from FORTRAN to C and from C to FORTRAN.

 There are two programs here. The first has a FORTRAN main and C
 subroutine; the second a C main and FORTRAN subroutine. Each program
 does essentially the same thing -- passes an array of 5 INTEGER*4 and a
 character string to the subroutine, which then prints the values.

 C version 6.00 and FORTRAN version 5.00 were used in this example.
 FORTRAN needs to be built with C compatible libraries, and the modules
 need to be linked with the /NOE switch. Each module needs to be
 compiled with the same floating-point and memory-module options (for
 example, /AL /FPi).

 The following is the FORTRAN main:

 C Note that the passed string has a zero length C style string
 C appended so that it appends a NULL terminating character.

       INTERFACE TO SUBROUTINE CPRINT [C] (I,STRING)
       INTEGER*4 I [REFERENCE]
       CHARACTER*(*) STRING [REFERENCE]
       END

       PROGRAM FMAIN

       INTEGER*4 I(5)
       CHARACTER*255 PRINTSTRING /'This example shows passing an array an
      +d a string.'/

       I(1) = 5
       I(2) = 4
       I(3) = 3
       I(4) = 2
       I(5) = 1

       CALL CPRINT(I,PRINTSTRING//''C)

       END

 The following is the start of the C subroutine:

 #include <stdio.h>

 void cprint(long int i[], char * printstring)
 {
   int count;

   printf("\n");
   for (count = 0; count < 5;count++)
     printf("\t%li",i[count]);
   printf("\n");

   printf("%s",printstring);
 }

 The following is the start of the C main program:

 extern void fortran fprint (long int *, char *);

 main ()
 {
     long int i[5];
     char printstring[255] = "This example shows passing an array and"
                             " a string.";

     i[0] = 5;
     i[1] = 4;
     i[2] = 3;
     i[3] = 2;
     i[4] = 1;

     fprint(i,printstring);
 }

 The following is the start of the FORTRAN subroutine:

 C The declaration of PRINTSTRING has to be equal to or less than the
 C size of the string passed from C. If it is not, other data will get
 C accessed, possibly causing a protection violation under OS/2.

       SUBROUTINE FPRINT (I,PRINTSTRING)
       INTEGER*4 I(*)
       CHARACTER*255 PRINTSTRING

       INTEGER  J

 C The following line truncates the string at the end of the C string.
 C (The C string end-of-string character is CHAR(0).)
       PRINTSTRING = PRINTSTRING(1:INDEX(PRINTSTRING,CHAR(0)))

       WRITE (*,*) (I(J),J=1,5)
       WRITE (*,*)
 C The substring (1:lentrim()) is printed instead of just the
 C variable because this way only the characters stored in the
 C variable are printed, and not the entire length of the variable
 C padded with spaces (255 spaces).
       WRITE (*,*) PRINTSTRING(1:LEN_TRIM(PRINTSTRING))
       END


 618. Multiplying by a Power of 2 Produces Wrong Results

 Product Version(s): 5.00   | 5.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | buglist5.00
 Last Modified:  2-JUL-1990    ArticleIdent: Q63360

 Incorrect results are produced in FORTRAN version 5.00 when
 multiplying an integer variable by a constant that is a power of 2
 if the result of the multiplication is larger than the range of the
 integer variable.

 This problem is a result of an overflow generated by the
 assembly-language code produced by the FORTRAN compiler. This problem
 does not occur if the result of the multiplication falls within the
 range of the integer variable. To work around this problem, use a
 variable instead of a constant to represent the multiplier.

 Microsoft is currently researching this problem and will post new
 information here as it becomes available.

 The following code example demonstrates the problem and the
 workaround:

   INTEGER*2 K/1234/
   INTEGER*2 L/31/, M/32/ ,N/33/
   WRITE(*,*) K*31, K*32, K*33 !Displays incorrect results for K*32
   WRITE(*,*) K*L, K*M, K*N    !Displays correct results for K*M
   END

 The following is the output from the program above:

    38254      -26048       40722
    38254       39488       40722

 The following is a fragment of the assembly listing, which shows the
 compiler does not detect overflow (use the /Fc compilation option to
 produce a combined source-assembly listing):

 ;|*** WRITE(*,*) K*31, K*32, K*33 !Displays incorrect results for K*32
         *** 00000f      a1 00 00                mov     ax,$S14_K
         *** 000012      b1 05                   mov     cl,5
         *** 000014      d3 e0                   shl     ax,cl
         *** 000016      99                      cwd
         *** 000017      52                      push    dx
         *** 000018      50                      push    ax
 ;|*** WRITE(*,*) K*L, K*M, K*N    !Displays correct results for K*M
         *** 000037      a1 00 00                mov     ax,$S14_K
         *** 00003a      f7 2e 04 00             imul    WORD PTR $S16_M
         *** 00003e      52                      push    dx
         *** 00003f      50                      push    ax

 In line 3a of the assembly-language listing, the integer variable K is
 correctly multiplied by the variable M (which is equal to 32), by
 using the IMUL instruction. The IMUL instruction is a signed multiply
 instruction that multiplies an implied destination operand by a
 specified source operand.

 In line 14, K is multiplied by 32 by shifting it left the number of
 positions specified by the corresponding power of 2. In this case, K
 is shifted five places to the left because 5 is the corresponding
 power of 2 for 32 (that is, 2^5 = 32). An overflow occurs because K is
 shifted left too many positions, which is what happens when the result
 of an integer is out of range.

 Overflow is not checked for, and thus, incorrect results are displayed
 as above. Also, if the number was converted to a double prior to the
 shift in the assembly-language code, the overflow would not have
 occurred (see lines 16 and 14 above).

 Disabling optimization has no effect.


 619. "R6001: Null Pointer Assignment" Caused by Loop Optimization

 Product Version(s): 5.00   | 5.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | buglist5.00
 Last Modified:  2-JUL-1990    ArticleIdent: Q63381

 Under some circumstances, programs compiled by the Microsoft FORTRAN
 compiler with loop optimization enabled cause the error "R6001: null
 pointer assignment" at run-time.

 The workaround for this problem is to disable loop optimization by
 compiling with either the /Od or /Odct switch. Using CHARACTER*10
 character strings also eliminates the problem in the example below.

 The following program demonstrates the problem:

       CHARACTER*1 STR1(10), STR2(10)
       DATA STR1 / 'T','.','B','.','C','.',4*' ' /
       CALL COPYSTR(STR1,1,10,STR2,1)
       END

       SUBROUTINE COPYSTR(IARRAY,IBEG,IEND,JARRAY,JBEG)
       CHARACTER*1 IARRAY(10),JARRAY(10)

       JPT = JBEG
       DO 100 IGET=IBEG,IEND
         JARRAY(JPT) = IARRAY(IGET)
         JPT = JPT+1
  100  CONTINUE
       RETURN
       END

 Microsoft is currently researching this problem and will post new
 information here as it becomes available.


 620. FORTRAN Err Msg: R6009: Not Enough Space for Environment

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

 The run-time error "R6009: not enough space for environment"
 sometimes occurs when the default data segment, or DGROUP, is nearing
 the 64K segment limit. The solution is to use the /Gt switch when
 compiling all modules of the program.

 The /Gt switch frees space in the default data segment by moving data
 items greater than a specified size into far data segments. /Gt4
 should be used for optimal results.

 Please refer to Section 7.6, Page 326, of the "Microsoft FORTRAN
 Reference" manual for more information about the /Gt switch.


 621. L2025 Errors in CHKSTK.ASM with FORTRAN 5.00 and C 6.00

 Product Version(s): 5.00   | 5.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | S_C mixed language
 Last Modified:  9-JUL-1990    ArticleIdent: Q63440

 When linking Microsoft FORTRAN version 5.00 and C version 6.00 object
 modules, the following three errors may occur:

    error L2025: STKHQQ : symbol defined more than once
    error L2025: __aaltstkovr : symbol defined more than once
    error L2025: __chkstk : symbol defined more than once

 These three symbols reside in the CHKSTK.ASM module within the FORTRAN
 and C libraries. To eliminate these error messages, use the Library
 Manager (LIB.EXE) to remove the CHKSTK module from the FORTRAN library
 as follows:

    LIB LLIBFORE-CHKSTK;

 Substitute the name of the appropriate FORTRAN library for LLIBFORE
 above.

 The following code demonstrates the problem when compiled
 and linked as indicated below:

       read(*,*) i
       write(*,*) i
       end

 fl /FPi /c test.for
 link test,,,/noe /nod llibce.lib llibfore.lib;

 The FORTRAN library was built with C compatibility.

 Microsoft is researching this problem and will post new information
 here as it becomes available.


 622. Calling MS-DOS Interrupt 21 Hex from FORTRAN Version 5.00

 Product Version(s): 5.00
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 24-JUL-1990    ArticleIdent: Q63464

 The C INTDOS and INTDOSX routines in Microsoft FORTRAN version 5.00
 are built into the FORTRAN run-time libraries. These two routines can
 be used to call the MS-DOS interrupt 21 hex.

 INTDOS invokes the MS-DOS system call specified by registers passed to
 it and returns the result of the system call in another set of
 registers. INTDOSX invokes the MS-DOS system call in the same manner
 as INTDOS, but also accepts segment register values.

 Listed below are two FORTRAN sample programs and an include file that
 demonstrates how to use INTDOS and INTDOSX.

 Note: INTDOS and INTDOSX are not available with FORTRAN run-time
 libraries built for C compatibility. Using these routines with the C
 run-time libraries may cause unexpected results.

 Microsoft cannot guarantee that the information stated here regarding
 how to use INTDOS and INTDOSX will perform all MS-DOS system calls
 correctly because this information has not been tested rigorously and
 is not considered a feature of the product. Also, Microsoft cannot
 guarantee that this information will remain unchanged or work
 correctly in future releases of the Microsoft FORTRAN Compiler.

 This information applies to the Microsoft FORTRAN Compiler version
 5.00 for MS-DOS.
 The INTDOS and INTDOSX routines are not documented in either the
 "Microsoft FORTRAN Reference" manual or the "Microsoft FORTRAN
 Advanced Topics" manual. However, these routines are documented on
 Pages 247-248 in the Microsoft C Compiler version 6.00 "Microsoft C
 Reference" manual and Page 365 in the Microsoft C Compiler version
 5.10 "Microsoft C Run-Time Library Reference" manual.

 The file below, INTDOS.INC, is the FORTRAN include file for the INTDOS
 and INTDOSX routines. This file includes the INTERFACE to the C
 routines and the register structures needed for these routines.

 c INTDOS.INC : include file for INTDOS and INTDOSX.

       INTERFACE TO SUBROUTINE INTDOS [C] (inregs,outregs)
       structure /regs/
           integer*2 ax,bx,cx,dx,si,di,flags
       end structure
       record /regs/ inregs  [REFERENCE]   ! Regs into INTDOS
       record /regs/ outregs [REFERENCE]   ! Regs returned
       end

       INTERFACE TO SUBROUTINE INTDOSX [C] (inregs,outregs,segregs)
       structure /regs/
           integer*2 ax,bx,cx,dx,si,di,flags
       end structure
       structure /sregs/
           integer*2 es,cs,ss,ds
       end structure
       record /regs/ inregs   [REFERENCE] ! Regs into INTDOS
       record /regs/ outregs  [REFERENCE] ! Regs returned
       record /sregs/ segregs [REFERENCE] ! Segment registers
       end

       implicit a-g

       structure /wordregs/                  ! Full word registers
           integer*2 ax,bx,cx,dx,si,di,flags
       end structure

       structure /sregs/                     ! Segment registers
           integer*2 es,cs,ss,ds
       end structure

       record /wordregs/ inregs,outregs
       record /sregs/ segregs

 The following program is an example of calling the INTDOS routine:

 c Call the MS-DOS interrupt 21 hex, with function 2A hex to get the
 c system date.

       include 'intdos.inc'

       gethibyte (dataword) = dataword / 256
       getlobyte (dataword) = iand(dataword,255)

       inregs.ax=#2a00                    ! Function number
       call intdos(inregs,outregs)        ! Call DOS interrupt
       write(*,*) ' Month= ',gethibyte(outregs.dx) ! High byte is month
       write(*,*) ' Day  = ',getlobyte(outregs.dx) ! Low byte is day
       write(*,*) ' Year = ',outregs.cx            ! Year
       end

 The following program is an example of calling the INTDOSX routine:

 c Call the MS-DOS interrupt 21 hex, with function 41 hex to delete a
 c file. This example uses the segment registers.

       include 'intdos.inc'
       character filename*12              ! File to delete
       integer*2 flen                     ! Length of filename
       integer*4 addr                     ! Location of filename
       print 10
    10 format (' Enter name of file to delete -> ',$)
       read (*,'(a)') filename            ! Get the file to delete
       flen=len_trim(filename)            ! Remove extra spaces
       filename=filename(:flen)//char(0)  ! Must be an ASCIIZ filename
       addr=locfar(filename)              ! Get the segment and offset
                                          ! of the file
       inregs.dx=iand(addr,#FFFF)
       segregs.ds=ishft(addr,-16)
       inregs.ax=#4100                         ! Function number
       call intdosx(inregs,outregs,segregs)    ! Call DOS interruptx
       if (iand(outregs.flags,1).eq.0) then    ! No error on delete
         write (*,*) 'File deleted successfully!'
       else                                    ! Error if carry is set
         write (*,*) ' File not deleted!  Status= ', outregs.ax
       endif
       end

 Note: Using a similar method to call the INTDOS routine causes a
 "Protection Violation" under OS/2 and hanging under DOS. This occurs
 when compiling a program that uses the EQUIVALENCE statement to cause
 two variables defined as STRUCTUREs to occupy the same memory location
 and compiling with the /Zi option.  For additional information
 concerning this problem, query on the following words:

      INTDOS and PROTECTION VIOLATION and /Zi


 623. Compiling FORTRAN Programs in the M Editor

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

 To compile Microsoft FORTRAN version 5.00 programs and view error
 messages within the M Editor, add the following lines to the TOOLS.INI
 file:

    extmake:.for.obj fl /c /nologo %|F
    Nextmsg:Shift+F3

 This information applies to the Microsoft FORTRAN Compiler version
 5.00 for MS-DOS and OS/2 and the Microsoft Editor version 1.02 for
 MS-DOS and OS/2.

 To compile a FORTRAN program that is loaded in the M Editor, type
 ALT+A, CTRL+F3. This will run a compilation according to the extmake
 switch above. In the extmake switch above, %|F tells the M Editor to
 compile the program that has been loaded. Other compile options can
 also be added to the extmake switch. If error messages are generated,
 they will appear at the bottom of the screen and the cursor will be
 placed at the corresponding error in the program. To move the cursor
 location to the next error message, press SHIFT+F3.

 At least 480K must be free before executing the M Editor when
 compiling FORTRAN programs that are loaded in the M Editor. A "D2027 :
 could not execute `C:\f1.exe'" error may occur if not enough memory is
 available. For more information on this topic, query on the following
 words:

      D2027 and M EDITOR

 Note: The /nologo compilation option is an undocumented option that
 stops the Microsoft copyright logo from appearing when compiling.
 Compiling programs in the M Editor under MS-DOS require use of the
 /nologo option; otherwise, the first error message will not be
 displayed. For more information on this problem, query on the word
 "NOLOGO".

 Additional information regarding compiling, invoking compilers and
 other utilities, and viewing error output can be found on Pages 44-47
 in the "Microsoft Editor User's Guide," which is included with FORTRAN
 version 5.00.


 624. Expression Too Complex on a CALL Statement in FORTRAN 5.00

 Product Version(s): 5.00   | 5.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | buglist5.00
 Last Modified:  9-JUL-1990    ArticleIdent: Q63645

 In Microsoft FORTRAN version 5.00, "fatal error F1035: expression too
 complex, please simplify" is generated on the CALL statement when
 compiling the following FORTRAN program:

       CHARACTER*1 FILE8, FILE9, FILEA, FILEB
       CHARACTER*1 OUT1, OUT2, OUT3, OUT4, OUT5
       CHARACTER*1 TITLEE, TITLET
 C
       CALL IPEXP
      &  (DSFILE, DSOIL, EFFIRR, EXPTNO, FILE1, FILE2, FILE4, FILE5,
      &  FILE6, FILE7, FILE8, FILE9, FILEA, FILEB, IIRR, INSTE, ISIM,
      &  ISOILT, ISOW, ISWNIT, MTRT, NFEXP, NREP, NSFILE, NTRT,
      &  NWFILE, OUT1, OUT2, OUT3, OUT4, OUT5, PHINT, PLANTS, ROWSPC,
      &  RUNALL, RUNEND, SDEPTH, SITEE, THETAC, TITLEE, TITLET)
       END

 The following is the FL command line used to compile the FORTRAN
 program above and generate the "expression too complex" error:

    FL /c /Fs test.for

 The exact combination of variable declarations and CALL statement will
 generate the "expression too complex error." Rearranging the order of
 the variables in the CALL statement or in the declarations or changing
 the variable names will prevent this error from occurring.

 Microsoft is researching this problem and will post new information
 here as it becomes available.

 This information applies to the Microsoft FORTRAN Compiler version
 5.00 for MS-DOS and OS/2.

 Disabling optimization does not inhibit generation of the error "fatal
 error F1035: expression too complex, please simplify."

 For more information on the F1035 error, see Page 415 in the
 "Microsoft FORTRAN Reference" manual.


 625. Size Comparison Charts for FORTRAN 4.x and 5.00 Libraries

 Product Version(s): 4.00 4.01 4.10 5.00 | 4.10 5.00
 Operating System:   MS-DOS              | OS/2
 Flags: ENDUSER |
 Last Modified:  9-JUL-1990    ArticleIdent: Q63658

 The following tables include the sizes, in bytes, of the coprocessor,
 emulator, and alternate math libraries for Microsoft FORTRAN versions
 4.00, 4.01, 4.10, and 5.00. The libraries were built with and without
 C compatibility for the medium and large memory models, and for DOS
 and OS/2 as applicable.

 Note the following:

 1. All libraries listed below were built to include error message
    text. Subtract approximately 2.5K from the size of the library
    if error message text was not included.

 2. The libraries listed do not include compatibility with FORTRAN
    versions 3.20 and 3.30 (this option is available with FORTRAN
    versions 4.00, 4.01, and 4.10, but not version 5.00). Including
    3.20/3.30 compatibility increases the library size by approximately
    4K for the coprocessor and emulator libraries, and 6K for the
    alternate library.

 The following abbreviations are used in the tables below:

 L - Large memory model          7 - Coprocessor library
 M - Medium memory model         E - Emulator library
 R - Real mode (DOS)             A - Alternate library
 P - Protected mode (OS/2)

 --------------------------------------------------------------------
 |      |   Without C Compatibility   |     With C Compatibility    |
 | 5.00 |-----------------------------|-----------------------------|
 |      |     7         E         A   |     7         E         A   |
 |------|-----------------------------|-----------------------------|
 | L  R | 205,741   218,541   218,287 | 186,173   198,973   199,745 |
 | L  P | 201,637   213,927   213,663 | 185,659   197,947   199,231 |
 |------|-----------------------------|-----------------------------|
 | M  R | 202,105   214,905   215,197 | 183,067   195,355   196,673 |
 | M  P | 198,003   210,293   210,575 | 182,553   194,841   196,159 |
 --------------------------------------------------------------------

 --------------------------------------------------------------------
 |      |   Without C Compatibility   |     With C Compatibility    |
 | 4.10 |-----------------------------|-----------------------------|
 |      |     7         E         A   |     7         E         A   |
 |------------------------------------------------------------------|
 | L  R | 188,437   200,725   202,023 | 171,475   183,763   183,527 |
 | L  P | 185,389   197,679   198,967 | 171,995   184,283   183,535 |
 |------|-----------------------------|-----------------------------|
 | M  R | 184,807   197,095   198,937 | 168,371   180,659   180,455 |
 | M  P | 181,761   194,051   195,883 | 168,379   181,179   180,463 |
 --------------------------------------------------------------------

 --------------------------------------------------------------------
 |      |   Without C Compatibility   |     With C Compatibility    |
 | 4.01 |-----------------------------|-----------------------------|
 |      |     7         E         A   |     7         E         A   |
 |------------------------------------------------------------------|
 | L  R | 185,955   197,731   197,821 | 167,933   179,709   177,749 |
 |------|-----------------------------|-----------------------------|
 | M  R | 181,813   193,589   194,223 | 164,317   176,605   174,677 |
 --------------------------------------------------------------------

 --------------------------------------------------------------------
 |      |   Without C Compatibility   |     With C Compatibility    |
 | 4.00 |-----------------------------|-----------------------------|
 |      |     7         E         A   |     7         E         A   |
 |------------------------------------------------------------------|
 | L  R | 182,272   194,048   194,048 | 168,473   180,249   178,289 |
 |------|-----------------------------|-----------------------------|
 | M  R | 178,176   189,952   190,464 | 165,369   177,145   175,217 |
 --------------------------------------------------------------------


 626. Recursion Not Supported by FORTRAN

 Product Version(s): 4.00 4.01 4.10 5.00 | 4.10 5.00
 Operating System:   MS-DOS              | OS/2
 Flags: ENDUSER |
 Last Modified: 16-JUL-1990    ArticleIdent: Q63819

 Recursion is not supported by the Microsoft FORTRAN Optimizing
 Compiler. This information is stated in the following manuals:

 1. The "Microsoft FORTRAN Reference" manual for FORTRAN version 5.00
    on Pages 127, 172, 225, and 231

 2. The "Microsoft FORTRAN Optimizing Compiler Language Reference"
    manual for FORTRAN versions 4.00, 4.10, and 4.01 on Pages 174, 218,
    and 273

 3. The "ANSI X3.9-1978 FORTRAN 77" standard in Section 15.2 on
    Page 15-1

 This information applies to the Microsoft FORTRAN Optimizing Compiler
 versions 4.00, 4.01, 4.10, and 5.00 for MS-DOS and OS/2.

 The following is the information about support for recursion from
 Section 15.2 of the "ANSI X3.9-1978 FORTRAN 77" standard:

      A subprogram must not reference itself, either directly or
      indirectly.

 Direct recursion is when a subroutine calls itself. Page 231 of the
 "Microsoft FORTRAN Reference" manual for FORTRAN version 5.00 states
 that "any attempt at direct recursion results in a compile-time error
 [F2600: name : directly recursive]."

 Indirect recursion is when a subroutine calls another subprogram,
 which in turn calls the first subroutine before the first subroutine
 has completed execution. Page 231 of the "Microsoft FORTRAN Reference"
 manual for FORTRAN version 5.00 states that indirect recursion is not
 detected.


 627. /Zi and EQUIVALENCEing RECORD Variables Hangs Machine

 Product Version(s): 5.00   | 5.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified: 24-JUL-1990    ArticleIdent: Q63839

 In Microsoft FORTRAN version 5.00, you will receive a protection
 violation in OS/2 and will hang in DOS when you compile a program that
 uses the EQUIVALENCE statement to cause two variables specified as
 user-defined STRUCTUREs to occupy the same memory location and then
 compile with the /Zi option. The FORTRAN program listed below
 demonstrates this problem.

 Microsoft is currently researching this problem and will post new
 information here as it becomes available.

 The following is the Microsoft FORTRAN program that generates a
 protection violation in OS/2 and hangs in DOS when you compile with
 the /Zi option:

       structure /wordregs/          ! Full word registers
           integer*2 ax
       end structure

       structure /byteregs/          ! High and low registers
           integer*1 ah,al
       end structure

       record /wordregs/ inregs1
       record /byteregs/ inregs2

       equivalence (inregs1,inregs2) ! This statement causes the
                                     ! problem.
       end

 The sample program above is a fragment of a complete FORTRAN program
 that demonstrates how to use the C routines, INTDOS and INTDOSX to
 call MS-DOS interrupt 21 hex. Equivalencing the variables inregs1 and
 inregs2 allows accessing both the word and high-and-low bytes of the
 8086 general registers. For more information on how to use the INTDOS
 and INTDOSX routines, query on the following words:

    INTDOS and INTERFACE

 More information concerning the EQUIVALENCE and STRUCTURE statements
 can be found on Pages 164-166 and 228-229, respectively, in the
 "Microsoft FORTRAN Reference" manual.

 The /Zi option prepares for debugging with Microsoft CodeView
 debugger. More information concerning the /Zi option can be found on
 Pages 357-358 in the "Microsoft FORTRAN Reference" manual.


 628. Environment Variables in STARTUP.CMD in FORTRAN

 Product Version(s): 5.00
 Operating System:   OS/2
 Flags: ENDUSER | docerr
 Last Modified: 23-JUL-1990    ArticleIdent: Q64018

 Contrary to what is stated in the "Microsoft FORTRAN Getting Started"
 booklet included with Microsoft FORTRAN version 5.00, SET statements
 for environment variables should not be included in the STARTUP.CMD
 file. These statements should be included in the CONFIG.SYS file, an
 OS2INIT.CMD file, or in another .CMD file that is executed before
 FORTRAN is used.

 The FORTRAN version 4.10 manuals do not contain this documentation
 error, but the information included below about setting up the
 environment also applies to version 4.10.

 Page 20 of the "Microsoft FORTRAN Getting Started" booklet included
 with FORTRAN 5.00 states the following:

    The environment-setting commands can be included in your
    AUTOEXEC.BAT or STARTUP.CMD file to ensure that the compiler
    environment is properly set up each time you reboot.

 This is correct for the DOS AUTOEXEC.BAT file but not for the OS/2
 STARTUP.CMD file. Both files are executed when a machine running their
 respective systems is booted, but the environment variables set in
 STARTUP.CMD are only recognized by the OS/2 screen group that executes
 the .CMD file. If another OS/2 screen group is started, STARTUP.CMD is
 not automatically executed and the environment set by it in the
 original screen group does not affect the new screen group.

 To ensure that the environment settings required by FORTRAN are set
 under OS/2, the PATH, SET LIB, SET TMP, SET INIT, and SET INCLUDE
 statements should be included in the CONFIG.SYS file, in an
 OS2INIT.CMD file, or in a .CMD file that is executed before working
 with FORTRAN.

 Environment variables can be set in the CONFIG.SYS file for OS/2
 versions 1.10 and later. The variables set there are recognized by
 each OS/2 screen group. This feature is not available in version 1.00
 of OS/2. In this case, an OS2INIT.CMD file can be used to set the
 environment.

 The OS2INIT.CMD file is the OS/2 equivalent to the DOS AUTOEXEC.BAT in
 terms of setting the environment for an OS/2 screen group. To use
 OS2INIT.CMD, the /K option for CMD.EXE must be included in the
 PROTSHELL statement of CONFIG.SYS.

 For example:

    PROTSHELL=... ... C:\0S2\CMD.EXE /K OS2INIT.CMD

 The file specified after the /K option is executed every time a new
 screen group is started. Any name can be used for the .CMD file.


 629. Multithreaded Programming Between FORTRAN 5.00 and C 5.10

 Product Version(s): 5.00
 Operating System:   OS/2
 Flags: ENDUSER | S_C multiple threads
 Last Modified: 27-JUL-1990    ArticleIdent: Q64192

 Multithreaded programming between languages is not recommended, as
 stated on Page 51 of the "Microsoft FORTRAN Advanced Topics" manual
 for version 5.0. However, when certain guidelines are followed as
 outlined below, multithreaded programming between Microsoft FORTRAN
 version 5.00 and Microsoft C version 5.10 will work correctly.

 Use the following guidelines:

 1. I/O within a thread should be done only in the language that
    created the thread.

 2. The FORTRAN BEGINTHREAD, ENDTHREAD, and THREADID routines must
    be used for thread control in FORTRAN rather than the C
    _beginthread, _endthread, or _threadid routines.

 3. The OS/2 API calls DosCreateThread and DosExit should not be
    used with FORTRAN.

 The results are unpredictable if the above guidelines are not
 followed.

 The example below demonstrates multithread programming between FORTRAN
 5.00 and C 5.10. It will not function correctly with C 6.00 because of
 changes between C 5.10 and C 6.00.

 Pages 49-60 of the "Microsoft FORTRAN Advanced Topics" manual for
 version 5.0 contain additional information about OS/2 programming and
 threads with FORTRAN. The MTDYNA.DOC file that is included on the C
 5.10 Compiler 2 Disk contains similar information for C.

 The following code demonstrates how to include FORTRAN as a secondary
 thread. The FORTRAN subroutine fsub will perform input/output
 operations, so the thread containing fsub must be started from
 FORTRAN. The fthread subroutine begins the new thread. Notice that
 the FORTRAN subroutine can call C routines to access global variables
 or perform routine processing better handled by C.

 The output of the program below is as follows:

    Data received OK

 In this example the os2.lib and os2.h files were taken from the
 "Microsoft OS/2 Presentation Manager Toolkit."

 # ------------------ File test (MAKE file) ------------------

 test.obj: test.c
    cl -Zi -c -G2sw -FPi -Alfw test.c

 fsub.obj: fsub.for
    fl -Zi -c -G2sw -FPi -MT fsub.for

 test.exe: test.obj fsub.obj
    link /NOE /NOD /CO test+fsub, /align:16,,  \
    llibfmt+llibcmt+os2,test.def

 // ----------------- File test.c (Main Program) --------------------

 #define INCL_DOSPROCESS
 #include <os2.h>
 #include <mt\process.h>
 #include <mt\stdio.h>
 #include <mt\stdlib.h>

 short    n1=12, n2=6, n3=16, n4=8;
 ULONG    MySemaphore;

 void main(void);
 void far pascal fthread(void far *);
 void fdone(void);
 void getdat(short *,short *,short *,short *);

 void main()
 {
    BYTE     *abStack;

    DosSemSet(&MySemaphore);
    abStack = (BYTE *) malloc(8192);
    fthread(abStack);
    /*             ...
          Go about other business here
                   ...                     */
    DosSemWait(&MySemaphore,SEM_INDEFINITE_WAIT);
    if (abStack != NULL) free(abStack);
 }

 void fdone()
 {
    DosSemClear(&MySemaphore);
 }

 void getdat(i1, i2, i3, i4)
 short *i1, *i2, *i3, *i4;
 {
    *i1 = n1;
    *i2 = n2;
    *i3 = n3;
    *i4 = n4;
 }

 C --------------- File fsub.for (FORTRAN subroutines) --------------

       INTERFACE TO INTEGER*2 FUNCTION BEGINTHREAD(RTN,STK,SIZE,ARG)
       INTEGER*4      RTN [VALUE]
       INTEGER*1      STK(*)
       INTEGER*4      SIZE
       INTEGER*4      ARG
       END

       INTERFACE TO SUBROUTINE ENDTHREAD()
       END

       INTERFACE TO SUBROUTINE FDONE [C] ()
       END

       INTERFACE TO SUBROUTINE GETDAT [C] (N1,N2,N3,N4)
       INTEGER*2         N1 [REFERENCE]
       INTEGER*2         N2 [REFERENCE]
       INTEGER*2         N3 [REFERENCE]
       INTEGER*2         N4 [REFERENCE]
       END

       subroutine fthread(stack)
       integer*1   stack(*)
       integer*2   tid, beginthread
       external    fsub
       tid = beginthread(LOCFAR(fsub),stack,8192,0)
       return
       end

       subroutine fsub()
       logical     dataok
       integer*2   n1, n2, n3, n4
       call getdat(n1, n2, n3, n4)
       dataok = (n1 .eq. 12 .and. n2 .eq. 6 .and. n3 .eq. 16 .and.
      1          n4 .eq. 8)
       if (dataok) then
          write(*,*) 'Data received OK'
       else
          write(*,*) 'Data NOT received OK'
       endif
       call fdone
       call endthread()
       end

 ; ---------------- File test.def (DEFINITIONS file) -----------------

 NAME TEST WINDOWCOMPAT
 PROTMODE
 CODE LOADONCALL
 DATA LOADONCALL NONSHARED


 630. BASIC Code in FORTRAN 5.00 Advanced Topics Manual Is Incorrect

 Product Version(s): 5.00   | 5.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | docerr B_QuickBas B_BasicCom
 Last Modified:  1-AUG-1990    ArticleIdent: Q64318

 The example on Page 90 of the "Microsoft FORTRAN Advanced Topics"
 manual for version 5.0 has omitted some required BASIC source code.

 If the BASIC code is compiled as suggested, and then linked to the
 FORTRAN subroutine, running the program produces the following error:

    run-time error F6700
    - heap space limit exceeded

 This error occurs because the FORTRAN subroutine does not have any
 heap space set up for it to use. This must be done in the BASIC code
 by adding the following lines:

    DIM HEAP%(2048)
    COMMON SHARED /nmalloc/ HEAP%()

 This will declare a heap size of 2K for FORTRAN to use.

 The following is the corrected code for the BASIC main:

 ' BASIC source
 '
 DIM HEAP%(2048)
 COMMON SHARED /nmalloc/ HEAP%()
 '
 DEFINT A-Z
 DECLARE SUB Fprog ()
 CALL Fprog
 END
 '
 FUNCTION Dbl (N) STATIC
      Dbl = N*2
 END FUNCTION
 '
 SUB Printnum (A,B) STATIC
      PRINT "The first number is ";A
      PRINT "The second number is ";B
 END SUB


 631. SYS2070 Error with FORTRAN Dynamic-Link Libraries

 Product Version(s): 5.00
 Operating System:   OS/2
 Flags: ENDUSER | sys 2070 DLL
 Last Modified:  3-AUG-1990    ArticleIdent: Q64447

 The error below occurs when running a Microsoft FORTRAN program that
 uses dynamic-link libraries and has been linked using the /NOI switch.
 The error may also occur if there are bad sectors on the hard disk or
 if a library is corrupt.

    SYS2070: The system could not demand load the
    application's segment.

 To alleviate this error, do not link with the /NOI switch or rebuild
 the library.

 The program below demonstrates the error when compiled and
 linked as follows:

 FL /MD /c sample.for
 LINK sample frtexe.obj,,,frtlib doscalls /NOI;

       PROGRAM SAMPLE
       WRITE(*,*) 'HELLO WORLD'
       END

 The above program generates the following error when run:

    SYS2070: The system could not demand load the
    application's segment.  FRTLIB __FFwr is in error.

 FRTLIB.LIB and FRTLIB.DLL were created by running the FDLLOBJS.CMD
 file that is included on the OS/2 Support 1 Distribution Disk for
 FORTRAN. FRTEXE.OBJ and DOSCALLS.LIB are also included with FORTRAN.

 To run the program, FRTLIB.DLL must reside in a directory that is
 pointed to by the LIBPATH variable in the CONFIG.SYS file.

 For more information about dynamic-link libraries and FORTRAN, see
 Pages 61-70 of the "Microsoft FORTRAN Advanced Topics" manual for
 version 5.0.


 632. Internal Compiler Error: getattrib.c:1.4, Line 174 in FORTRAN

 Product Version(s): 5.00    | 5.00
 Operating System:   MS-DOS  | OS/2
 Flags: ENDUSER | buglist5.00 SR# S900727-117
 Last Modified: 14-AUG-1990    ArticleIdent: Q64596

 The code below generates the following error:

    fatal error F1001: Internal Compiler Error
    (compiler file '@(#)getattrib.c:1.4', line 174).

 The error is produced when a program contains the following:

 1. The AUTOMATIC statement

 2. A structure variable that has an array as an element

 3. An implicit READ or WRITE of the array structure element

 The following code produces the error:

          AUTOMATIC

          STRUCTURE /struc/
            INTEGER var(2)
          END STRUCTURE

          RECORD /struc/ test

          READ(*,*) test.var

          END

 To work around this problem, either remove the AUTOMATIC statement or
 do not read or write the array implicitly.

 Microsoft has confirmed this to be a problem in the FORTRAN compiler
 version 5.00. We are researching this problem and will post new
 information here as it becomes available.


 633. $FREEFORM Allows Lines to Be 80 Characters Long in FORTRAN

 Product Version(s): 4.00 4.01 4.10 5.00 | 4.10 5.00
 Operating System:   MS-DOS              | OS/2
 Flags: ENDUSER | docerr buglist5.00
 Last Modified:  9-JAN-1991    ArticleIdent: Q64611

 The standard format for lines in Microsoft FORTRAN allows for
 characters in columns 1 through 72. By using the $FREEFORM metacommand
 with FORTRAN versions 4.00, 4.01, 4.10, and 5.00, lines may have
 characters in columns 1 through 80. The limit is column 79 if the last
 character in the line is an apostrophe or single quotation mark (').

 The allowed line length in source code with the $FREEFORM metacommand
 is not explicitly stated in the FORTRAN manuals. Section 2.3,
 "Free-Form Source Code," on Page 46 in the "Microsoft FORTRAN
 Reference" manual for version 5.0 states that most of the rules
 applying to line formatting in Section 2.1 do not apply to free-form
 code. The rules state that any characters in column 73 and above are
 ignored. With the $FREEFORM metacommand characters in column 81 and
 above are ignored.

 The following code will demonstrate the limit:

 $FREEFORM

 aa  = 1
 aaa = 2

 WRITE (*,*)                     aaa !aaa starts in column 79
 END

 This program prints a "1" because the third "a" in the variable name
 is ignored.

 An exception to the 80-character length limit occurs when the last
 character in the line is an apostrophe or single quotation mark (').
 When this is the case, the compiler only accepts 79 characters on a
 line.

 Consider the following code:

 $FREEFORM

 WRITE (*,*)             'The closing quotation mark is in column 80'
 END

 When this code is compiled the following error is generated:

    ...error F2031 : closing quote missing


 634. $STORAGE:2 Causes Incorrect RETURN from a SUBROUTINE

 Product Version(s): 5.00   | 5.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | STORAGE return
 Last Modified: 16-AUG-1990    ArticleIdent: Q64847

 When a subroutine contains the $STORAGE:2 metacommand, a RETURN to an
 alternate return label will fail if the subroutine is in a separate
 file from the calling routine and the calling routine does not contain
 $STORAGE:2. This is caused by the inconsistent use of the $STORAGE:2
 metacommand. This error occurs under both DOS and OS/2, and only
 occurs in version 5.00 of Microsoft FORTRAN.

 Removing the $STORAGE:2 metacommand from the subroutine file, placing
 the subroutine in the same file as the calling routine, or placing the
 $STORAGE:2 metacommand in the calling-routine file corrects the
 problem. Optimization has no affect on this error.

 This problem occurs because the alternate return labels are considered
 to be integer arguments of a subroutine call, and thus fall under the
 control of the $STORAGE metacommand.

 Page 126 of the "Microsoft FORTRAN Reference" manual for version 5.0
 states in the "NOTE" section that there must be type agreement between
 the integer arguments of a subroutine and a calling program. To
 guarantee that the alternate return label types agree, the $STORAGE
 metacommand must be the same in both the calling routine and the
 subroutine files. A warning about the usage of $STORAGE with source
 code in multiple files is also found on Page 308 of the "Microsoft
 FORTRAN Reference" manual.

 The code listed below illustrates the problem:

 FILE 1:
 ------

       CALL SUB1 (*10)
       STOP '*10 DID NOT WORK'
 10    STOP '*10 DID WORK'
       END

 FILE 2:
 ------

 $STORAGE:2
       SUBROUTINE SUB1 (*)
       RETURN 1
       END

 The above program will print to the screen as follows:

 *10 DID NOT WORK

 If $STORAGE:2 is removed from FILE 2 or added to FILE 1, the program
 will print as follows:

 *10 DID WORK

 The program will also work correctly if the subroutine is placed in
 the same file.


 635. Undocumented FORTRAN Error "F2347: Missing Type"

 Product Version(s): 5.00   | 5.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | SR# G900201-54
 Last Modified: 16-AUG-1990    ArticleIdent: Q64848

 If IMPLICIT NONE is specified in a program, then all user-defined
 names must be explicitly typed.

 An untyped name causes the following undocumented compile-time error:

    F2347: missing type

 The program below demonstrates this error:

       implicit none
       x = 3
       end

 f2347.for(2) : error F2347: X : missing type

 To alleviate the error, declare the variable as in the following
 program:

       implicit none
       integer*4 x
       x = 3
       end


 636. Accessing Command-Line Arguments with FORTRAN

 Product Version(s): 4.00 4.01 4.10
 Operating System:   MS-DOS
 Flags: ENDUSER | appnote HF0220
 Last Modified: 28-AUG-1990    ArticleIdent: Q65236

 An application note called "Accessing Command-Line Arguments with
 FORTRAN," which explains how to access the command-line arguments
 under Microsoft FORTRAN versions 4.00, 4.01, and 4.10, is available
 from Microsoft Product Support Services by calling (206) 637-7096.

 This article contains the same information as the application note.
 Below is the code for the following FORTRAN files.

 Filename      Description
 --------      ------------

 PSPTST.FOR    Main program that contains the INTERFACE to DMPCMD and
               calls DMPCMD

 DMPCMD.FOR    Subroutine that prints the contents of the command line

 Note: DMPCMD must be compiled in a separate source file.

 How to Use PSPTST
 -----------------

 Use the following command to compile the two programs:

    FL PSPTST.FOR DMPCMD.FOR

 If PSPTST is invoked with a command line such as

    PSPTST hello

 the output will be as follows:

    < hello>

 In FORTRAN version 5.00, command-line arguments can be accessed using
 the NARGS function and the GETARG procedure described on Page 271 of
 the "Microsoft FORTRAN Reference" manual for version 5.00.

 The PSPTST Program
 ------------------

 c The INTERFACE statement is used to pass the addresses of the start
 c of the command line and the number of characters in the command line
 c to the separately compiled subroutine, DMPCMD, by value, instead of
 c by reference. The variables are passed by value because they are
 c themselves addresses. The DMPCMD subroutine is compiled separately
 c so that it will accept its arguments by reference. This results in
 c the two passed addresses being properly "dereferenced."
 c
       INTERFACE TO SUBROUTINE DMPCMD( II,JJ )
       INTEGER*4 II [VALUE], JJ [VALUE]
       END
 c
 c --------------------------------------------------------------------
       PROGRAM PSPTST
       INTEGER*4 PSP, PSPNCH, OFFSET
 c --------------------------------------------------------------------
 c The method used in this program will work only if the Program
 c Segment Prefix precedes the main program, which it will by
 c default. Since the PSP starts 16 paragraphs (256 bytes) before
 c the main program, the first step is to load the variable OFFSET
 c with the hex value 0010:0000, as follows:
 c
       OFFSET = #00100000
 c --------------------------------------------------------------------
 c Use LOCFAR to find the segment:offset of the main program:
 c
       PSP = LOCFAR(PSPTST)
 c --------------------------------------------------------------------
 c To set PSP so that it points to the start of the text of the
 c command line, do the following:
 c
 c 1. Zero out the offset portion of the address in variable PSP.
 c
 c 2. Subtract 16 paragraphs from the segment:offset.
 c
 c 3. Add hex 81 so that PSP now points to the start of the text of the
 c    command line:
 c
       PSP = (PSP-MOD(PSP,#10000))-OFFSET+#81
 c --------------------------------------------------------------------
 c PSPNCH points to the byte (80 hex) in the PSP that contains the
 c length of the command line:
 c
       PSPNCH = PSP-1
 c --------------------------------------------------------------------
 c Call DMPCMD to list out the command line:
 c
       CALL DMPCMD(PSP, PSPNCH)
       END

 The DMPCMD Subroutine
 ---------------------

 Note: Compile this routine in a file separate from PSPTST.

       SUBROUTINE DMPCMD(CMDLIN, N)
       CHARACTER*80 CMDLIN
       INTEGER*1 N
 c
 c Write out N characters from CMDLIN (N is PSP+80 hex; CMDLIN is
 c PSP+81 hex).
 c
       WRITE (*,*) '<',CMDLIN(:N),'>'
       RETURN
       END


 637. Compiler Errors F1002, F1901, R6000 Using Large Namelists

 Product Version(s): 5.00   | 5.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | buglist5.00
 Last Modified:  3-OCT-1990    ArticleIdent: Q65047

 In the code sample below, errors are produced when a READ operation is
 performed on a namelist that contains more than 99 variables.

 If the namelist contains

    100 - 106 variables

 the following errors are produced:

    F1002: out of heap space
    R6000 - stack overflow

 If the namelist contains

    107 - 117 variables

 the machine hangs under DOS or produces a protection violation under
 OS/2. If the namelist contains

    118 + variables

 the error is as follows:

    F1901: program too large for memory

 If the READ in the code below is changed to a WRITE, the errors are
 the same, except when the namelist contains 104 - 106 variables under
 OS/2. In this case, the screen group running the compiler will hang.

 Microsoft has confirmed this to be a problem in FORTRAN version 5.00.
 We are researching this problem and will post new information here as
 it becomes available.

 The following code will produce the errors:

       NAMELIST /test/
      * a001,a002,a003,a004,a005,a006,a007,a008,a009,a010
      *,a011,a012,a013,a014,a015,a016,a017,a018,a019,a020
      *,a021,a022,a023,a024,a025,a026,a027,a028,a029,a030
      *,a031,a032,a033,a034,a035,a036,a037,a038,a039,a040
      *,a041,a042,a043,a044,a045,a046,a047,a048,a049,a050
      *,a051,a052,a053,a054,a055,a056,a057,a058,a059,a060
      *,a061,a062,a063,a064,a065,a066,a067,a068,a069,a070
      *,a071,a072,a073,a074,a075,a076,a077,a078,a079,a080
      *,a081,a082,a083,a084,a085,a086,a087,a088,a089,a090
      *,a091,a092,a093,a094,a095,a096,a097,a098,a099,a100
      *,a101,a102,a103,a104,a105,a106,a107,a108,a109,a110
      *,a111,a112,a113,a114,a115,a116,a117,a118,a119,a120

       READ (*,test)
       END

 The workaround to this problem is to reduce the size of the namelist.
 This can be accomplished by either splitting the namelist into
 multiple smaller namelists or by grouping variables of similar type
 together using arrays.

 The following code uses an array instead of individual variables:

       real a(120)
       namelist/test/ a

       read (*,test)
       end


 638. IMAGESIZE_W Type Definition Is Incorrect in FGRAPH.FD

 Product Version(s): 5.00
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist5.00
 Last Modified: 22-AUG-1990    ArticleIdent: Q65048

 The graphics function IMAGESIZE_W is incorrectly typed in the
 FGRAPH.FD include file for Microsoft FORTRAN version 5.00. The
 function is typed as INTEGER*2 instead of INTEGER*4. It is typed
 correctly in both the "Microsoft Advanced Topics" manual and the
 FGRAPH.FI include file.

 When compiling a program that references IMAGESIZE_W, the following
 error is generated:

    F2220: IMAGESIZE_W : length redefined

 This error can be corrected by changing the line in the FGRAPH.FD file
 that reads

    INTEGER*2 IMAGESIZE_W

 to the following:

    INTEGER*4 IMAGESIZE_W

 Microsoft has confirmed this to be a problem in FORTRAN version 5.00.
 We are researching this problem and will post new information here as
 it becomes available.


 639. F2124: CODE GENERATION ERROR with Adjustable Arrays and $LARGE

 Product Version(s): 5.00   | 5.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | buglist5.00
 Last Modified: 22-AUG-1990    ArticleIdent: Q65049

 The error

    F2124: CODE GENERATION ERROR

 occurs when using adjustable-sized, three-dimensional arrays and the
 huge memory model with Microsoft FORTRAN version 5.00. Compiling with
 the /Od option will eliminate this error. Changing the order and size
 of the subscripts may also eliminate this error.

 The following sample code generates error F2124 when compiled with the
 /AH switch or $LARGE metacommand:

       SUBROUTINE X( a,b,i,j,m )
       DIMENSION a(m,2,2), b(2,m,2)

       a(i,2,1) = b(j,i,2)

       RETURN
       END

 Microsoft is researching this problem and will post new information
 here as it becomes available.


 640. Problems Indexing Arrays with INTEGER*1 Variables

 Product Version(s): 5.00   | 5.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | buglist5.00
 Last Modified:  5-SEP-1990    ArticleIdent: Q65414

 Erroneous results can be generated when using an INTEGER*1 variable to
 index an array. Changing the index to an INTEGER*2 variable, or
 compiling with the /4Yb switch will correct the problem.

 Microsoft has confirmed this to be a problem in FORTRAN version 5.00.
 We are researching this problem and will post new information here as
 it becomes available.

 The sample code below generates improper values when compiled using
 FORTRAN version 5.00. The error occurs when the compiler calculates
 the offset of certain array elements. If the number of bytes per
 element is a power of two, the compiler uses a shift instruction to
 multiply the index, calculating the element's offset from the
 beginning of the array.  Depending on the number of shifts and the
 initial value of the index, bits may be lost and/or shifted into the
 sign bit, resulting in incorrect offset values.

 The following is a sample code:

          integer*1 k
          integer*2 iarray(100)

          iarray = 0

          do k=1,100
             write(*,*) iarray(k)
          enddo
          end

 The screen output appears as follows:

        0
        .
        .
        .
        0     ( 63 zeros )
    25972
    26998
     3376
    12336
    29807
     8296
        .
        .
        .

 This example runs correctly when compiled with the /4Yb option.


 641. FORTRAN Err Msg: R6001 Null Pointer Assignment Using Namelist

 Product Version(s): 5.00   | 5.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | buglist5.00
 Last Modified: 24-SEP-1990    ArticleIdent: Q65607

 The compile time error

    run-time error R6001
    - null pointer assignment

 is generated when a NAMELIST group name is declared as a variable or
 is initialized as a variable before the NAMELIST is defined.

 Microsoft has confirmed this to be a problem in FORTRAN version 5.00.
 We are researching this problem and will post new information here as
 it becomes available.

 When the code below is compiled with Microsoft FORTRAN version 5.00, a
 null pointer assignment is generated:

       a=1
       NAMELIST /a/ b   ! 'a' is already a variable name
       END


 642. Incorrect Use of Structure Variable Hangs Compiler

 Product Version(s): 5.00   | 5.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | buglist5.00
 Last Modified: 24-SEP-1990    ArticleIdent: Q65608

 Compiling code that attempts to access an undefined element of a
 STRUCTURE hangs your machine under DOS and causes a protection
 violation under OS/2. The compiler should display the following:

    error F2509:  (element): not an element of (name)

 Microsoft has confirmed this to be a problem in FORTRAN version 5.00.
 We are researching this problem and will post new information here as
 it becomes available.

 When you compile with Microsoft FORTRAN version 5.00, the following
 code hangs the machine under DOS and causes a protection violation
 under OS/2:

       STRUCTURE /a/
          INTEGER b
       END STRUCTURE
       RECORD /a/ c

       c.b = c.b.d    ! b.d is not an element of c

       END


 643. PAUSE Command with Input Redirection in FORTRAN

 Product Version(s): 4.00 4.01 4.10 5.00 | 4.10 5.00
 Operating System:   MS-DOS              | OS/2
 Flags: ENDUSER | buglist5.00
 Last Modified: 27-NOV-1990    ArticleIdent: Q67098

 Beginning with Microsoft FORTRAN version 4.00, the PAUSE command
 allows you to execute operating system commands while program
 execution is suspended. When program input is redirected from the
 keyboard to a file, the PAUSE statement does not work correctly if the
 program READs from the redirection file or if the program contains
 multiple PAUSE statements.

 Microsoft has confirmed this to be a problem in FORTRAN versions 4.x
 and 5.00. We are researching this problem and will post new
 information here as it becomes available.

 When input is redirected from a file and the only data read from the
 file is one DOS command for a PAUSE statement, the program works
 correctly. The following short program gives an example:

 Code, TEST.FOR:

       write(*,*) 'Before PAUSE'
       pause
       write (*,*) 'After PAUSE'
       end

 Data file, TEST.DAT:

    Ver

 Command line:

    C:\> TEST < TEST.DAT

 Output:

    Before PAUSE
    Pause - Please enter a blank line (to continue) or a
      DOS command.

    MS-DOS Version x.xx

    After PAUSE

 If another PAUSE statement is added to the program, only the command
 for the first PAUSE is executed. The program appears to read to the
 end of the redirection file when it encounters the first PAUSE. If a
 READ statement is added to the program after the PAUSE statement, as
 in the next example, the program again reads to the end of the file.
 In this case, ERROR 6501 is generated.

 Code:

       integer i
       write(*,*) 'Before PAUSE'
       pause
       write (*,*) 'After PAUSE'
       read(*,*) i
       write (*,*) i
       end

 Data:

    Ver
    1

 Output:

    Before PAUSE
    Pause - Please enter a blank line (to continue) or a
      DOS command.

    MS-DOS Version x.xx

    After PAUSE
    run-time error F6501: READ(CON)
    - end of file encountered

 When the READ statement is before the PAUSE statement, the DOS command
 is not executed:

 Code:

       integer i
       read(*,*) i
       write (*,*) i
       write(*,*) 'Before PAUSE'
       pause
       write (*,*) 'After PAUSE'
       end

 Data:

    1
    Ver

 Output:

              1
    Before PAUSE
    Pause - Please enter a blank line (to continue) or a
      DOS command.

    After PAUSE

 These problems are caused by the PAUSE command not reading data from
 the redirection file in the same way a READ statement would.

 Workarounds
 -----------

 Do not use redirection on a program with more than one PAUSE
 statement or a combination of PAUSE and READ statements.

 Use the OPEN command to open a file to be used for input
 for READ statements.

 Use calls to the C functions SYSTEM or SPAWNLP instead of PAUSE
 statements to execute DOS commands. For more information on these
 functions, see page 86 of the "FORTRAN Advanced Topics" manual for
 version 5.00 or the DEMOEXEC.FOR program included with versions 4.x
 and 5.00 of FORTRAN.

 This problem does not occur in earlier versions of FORTRAN because the
 functionality of the PAUSE statement is different. In earlier
 versions, you are not allowed to execute DOS commands after a PAUSE.


 644. Problems Initializing Structure Arrays in DATA Statements

 Product Version(s): 5.00   | 5.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | buglist5.00
 Last Modified: 27-NOV-1990    ArticleIdent: Q67150

 Initializing indexed structures in DATA statements can produce the
 following compiler error in Microsoft FORTRAN when the DATA statement
 contains an implied DO-list and the structure contains an array as an
 element:

    F2414: DATA : not array-element name

 The following error occurs when the DATA statement contains an implied
 DO-list and the structure variable is an array:

    F2409: nonstatic address illegal in initialization

 The following errors occur when the array is specified without an
 index and the necessary amount of data to fill the array is then
 specified:

    F2537: VAR : array subscripts missing
    F4400 warning: DATA : more constants than names

 Microsoft has confirmed this to be a problem in FORTRAN version 5.00.
 We are researching this problem and will post new information here as
 it becomes available.

 The following code produces the compiler error

    F2414: DATA : not array-element name

 when a structure with an indexed element is initialized in a DATA
 statement with an implied DO-list. The commented DATA statement works
 correctly.

       INTEGER i

       STRUCTURE /struct/
          integer var(3)
       END STRUCTURE

       RECORD /struct/ test

       DATA (test.var(i), i=1,3) / 1, 2, 3 /

 C     DATA test.var(1), test.var(2), test.var(3) / 1, 2, 3 /

       write(*,*) test.var

       END

 The following code produces the compiler error

    F2409: TEST : nonstatic address illegal in initialization

 when an indexed structure is initialized in a DATA statement with an
 implied DO-loop. The commented DATA statement works correctly.

       INTEGER i

       STRUCTURE /struct/
          integer var
       END STRUCTURE

       RECORD /struct/ test(3)

       DATA (test(i).var, i=1,3) / 1, 2, 3 /

 C     DATA test(1).var, test(2).var, test(3).var / 1, 2, 3 /

       write(*,*) test.var

       END

 The following code produces the compiler error and warning

    F2537: VAR : array subscripts missing
    F4400 warning: DATA : more constants than names

 when no index is specified for a structure variable array or a
 structure element that is an array, and the necessary amount of data
 to fill the array is then specified. The commented DATA statement
 works correctly.

       INTEGER i, dummy_array(3)

       STRUCTURE /struct/
          integer var(3)
       END STRUCTURE

       RECORD /struct/ test

       DATA test.var / 1, 2, 3 /

 C     DATA dummy_array / 1, 2, 3 /

       write(*,*) test.var

       END

 Workarounds
 -----------

 Use a DO-loop and assignment statements.

 List each structure element in the DATA statement rather than using an
 implied DO-list.

 Use a DO-loop to READ in each element from a file. This last option
 does not work when the structure variable is an array. Reading a
 structure element in this case produces error F2725. For more
 information about this error, query on the following word:

    F2725

 Note: Using the patched version of F1.EXE and disabling optimization
 have no effect. For more information on the FORTRAN 5.00 patch, query
 on the following word:

    FORPATCH.ARC


 645. Compiler Errors in INCLUDE Files Not Flagged in Listing File

 Product Version(s): 5.00   | 5.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | buglist5.00
 Last Modified: 27-NOV-1990    ArticleIdent: Q67167

 When a compiler error occurs in an INCLUDE file, the compiler error
 messages do not appear in the source listing file generated by the
 Microsoft FORTRAN version 5.00 compiler. However, the total number of
 detected errors tallied at the end of the listing file is correct.

 Microsoft has confirmed this to be a problem in FORTRAN version 5.00.
 We are researching this problem and will post new information here as
 it becomes available.

 When the FL command is issued with the /Fs option, a source listing
 file is created that should contain any compiler errors next to the
 line of source code that generated the error. The errors are also sent
 to the screen and subsequently to the M editor, if compilation is
 being done from within the editor. If a compiler error is generated on
 a source line in an INCLUDE file, the error is correctly flagged on
 output to the screen and consequently to the editor, but not correctly
 inserted into the source listing file.

 In the following code, the INCLUDE file has one error (which is not
 flagged in the listing file), and the program source file has one
 error to demonstrate how the listing file should flag errors.

 Source file (foo.for):

       program main
       include 'test'
       write(*,*) 'This is a test'
       writ(*,*) 'This is also a bad line'
       end

 Include file (test):

       writ(*,*) 'This is a bad line'

 List file:

 PAGE   1

 11-14-90

 03:09:12

  Line#  Source Line          Microsoft FORTRAN Optimizing Compiler
 Version 5.00

      1        program main
      2        include 'test'
       ***** Begin listing of: test
      1        writ(*,*) 'This is a bad line'
       ***** End listing of: test
      3        write(*,*) 'This is a test'
      4        writ(*,*) 'This is also a bad line'
 ***** foo.for(4) : error F2115: syntax error
      5        end

 2 errors detected


 646. F1001: Internal Compiler Error, ctypes.c: with ICHAR Function

 Product Version(s): 4.00 4.01 4.10 5.00 | 4.10 5.00
 Operating System:   MS-DOS              | OS/2
 Flags: ENDUSER | buglist5.00
 Last Modified: 28-NOV-1990    ArticleIdent: Q67168

 When a nonarray character string is incorrectly used as an
 array in the ICHAR function, the following error is generated:

    F1001: Internal Compiler Error

 The compiler file listed depends on the version of FORTRAN used. The
 following are the different compiler files and line numbers listed
 by the errors generated by the different versions of FORTRAN:

    (compiler file @(#)ctypes.c:1.11, line 448)
       with FORTRAN 5.00,

    (compiler file @(#)ctypes.c:1.89, line 428)
       with FORTRAN 4.10,

    (compiler file @(#)ctypes.c:1.88, line 428)
       with FORTRAN 4.01,

    (compiler file @(#)ctypes.c:1.80, line 426)
       with FORTRAN 4.00.

 The following error should be generated:

    F2512: argument list illegal.

 Microsoft has confirmed this to be a problem in FORTRAN version 5.10.
 We are researching this problem and will post new information here as
 it becomes available.

 The following sample code produces this error:

       CHARACTER*5 strg

       ival = ICHAR(strg(j))

       END

 Note that "strg" is a nonarray character string and the ICHAR function
 is attempting to reference "strg" as an array. This error could be
 caused by incorrectly trying to reference a single character of
 "strg." To reference a single character, the ICHAR statement would
 have the following form:

    ival = ICHAR(strg(j:j))

 Substring manipulation is discussed on pages 17 and 18 of the
 "Microsoft FORTRAN Reference" manual for version 5.00 in the Elements
 of FORTRAN chapter.

 Also, if the character string "strg" is changed to CHARACTER*4 or
 less, the program compiles without an error, even though it still
 should generate a F2512 error.


 647. How to Avoid the "Program Too Large for Memory" FORTRAN Error

 Product Version(s): 4.00 4.01 4.10 5.00 | 4.10 5.00
 Operating System:   MS-DOS              | OS/2
 Flags: ENDUSER |
 Last Modified: 27-NOV-1990    ArticleIdent: Q67194

 When you attempt to run a very large program in DOS, the error
 "Program Too Large For Memory" may occur. MS-DOS runs in real mode,
 which does not allow more than 640K of memory for applications. This
 article discusses possible methods to circumvent this limitation.
 These methods include using the OS/2 operating system instead of DOS,
 direct-access disk file(s) for data storage, ALLOCATABLE arrays, and
 overlays.

 Using Expanded and Extended Memory with Microsoft FORTRAN
 ---------------------------------------------------------

 Some DOS applications can use an expanded memory manager (EMM) driver
 program and expanded memory board(s) to access memory beyond the 1 MB
 limit of conventional memory. Microsoft FORTRAN, however, does not
 have the capability to use expanded memory. It can utilize extended
 memory (above 1 MB), but only when used with the OS/2 operating system
 and protected mode libraries. Extended memory is the term used to
 refer to the memory at physical addresses above 1 MB that can be
 accessed by an 80286 or 80386 CPU in protected mode.

 Using a Direct Access Disk File to Store Large Amounts of Data
 --------------------------------------------------------------

 A disk drive can be used to store large amounts of data in a direct-
 access disk file, thus freeing up the memory that would otherwise be
 used by the data. By using a direct-access file, records can be read
 from or written to in any order, simulating the use of an array. If
 expanded or extended memory is available, it can be used for a RAM
 drive. By using a RAM drive, I/O access to the data is much faster
 than when using a fixed disk drive.

 Using Allocatable Arrays in FORTRAN Version 5.00
 ------------------------------------------------

 An ALLOCATABLE array is an array that is dynamically sized at run time
 by using the ALLOCATE statement and the ALLOCATABLE attribute (see
 pages 21-25 of the "Microsoft FORTRAN Reference" manual). The ALLOCATE
 statement (see pages 113-114 of the "Microsoft FORTRAN Reference"
 manual) establishes the upper and lower bounds of each ARRAY dimension
 and reserves sufficient memory. The array can then be DEALLOCATED at
 run time by using the DEALLOCATE statement (see page 143 of the
 "Microsoft FORTRAN Reference" manual) to free memory for use by other
 arrays.

 For example:

   INTEGER data [ALLOCATABLE] (:,:)
   INTEGER error
   DATA i, j / 10,50 /
   ALLOCATE (data (i,j), STAT=error)

   DEALLOCATE (data, STAT=error)

 Using Overlays in FORTRAN Versions 4.00, 4.01, 4.10, and 5.00
 -------------------------------------------------------------

 Overlays (see pages 366-367 of the "Microsoft FORTRAN Reference"
 manual for versions 5.00 and pages 258-260 of the "Microsoft FORTRAN
 CodeView and Utilities User's Guide") allow several program modules to
 use the same memory area. When needed, a module or group of modules is
 loaded into memory from the disk. Module access time can be shortened
 if a RAM drive is used to store the executable. Modules that are to be
 overlaid are enclosed in parentheses. CODE (but NEVER DATA) is
 overlaid. Note: If the program consists of mostly DATA, then this
 procedure will be of little help.

 The following example is for versions 4.00, 4.01, 4.10, and 5.00:

    At LINK command line: LINK A (B C) (E F)

    Object modules B and C are swapped in and out of the same memory for
    Object modules E and F. Note: Object modules in parentheses are
    overlaid together so that they will be loaded into memory at the
    same time.

 The following example is for versions 4.10 and 5.00:

    At FL command line: FL MAIN.FOR (OVER1.FOR) (OVER2.FOR)

    FORTRAN code modules OVER1 and OVER2 are swapped in and out of the
    same memory location.


 648. Using ANSI Escape Sequences to Clear the Screen

 Product Version(s): 3.20 3.30 3.31 4.00 4.01 4.10 5.00 | 4.10 5.00
 Operating System:   MS-DOS                             | OS/2
 Flags: ENDUSER |
 Last Modified: 27-NOV-1990    ArticleIdent: Q67195

 An ANSI escape sequence can be used within a FORTRAN program to clear
 the screen. Programs can use a subset of the ANSI 3.64-1979 standard
 escape sequences to erase the display, set the display mode and
 attributes, and control the cursor in a hardware-independent manner.

 In real mode, the ANSI.SYS device driver is used to support ANSI
 escape sequences. It is installed in the CONFIG.SYS file with the
 following command:

    DEVICE=[drive:][path]ANSI.SYS

 In protected mode, support for ANSI escape sequences come from an OS/2
 AVIO ("advanced video input/output") function.

 An ANSI escape sequence is a sequence of ASCII characters, the first
 two of which must be the escape character (char(27)) and the
 left-bracket character ([). The characters following the escape and
 left-bracket characters vary with the type of control function being
 performed.

 An escape sequence cannot be entered directly at the system prompt
 because each ANSI escape sequence must begin with an escape character.
 If you press the ESC key, MS-DOS cancels the command line.

 The following program uses the ANSI escape sequence (ESC[2J) to clear
 the screen:

       character*1 clrstr(4)
       data clrstr /' ','[','2','J'/
       clrstr(1) = char(27)            ! Escape character (ASCII 27).
       write (*,'(1x,4a1\)') clrstr    ! You must use a 1x as the first
       end                             ! part of the format specifier
                                       ! to ensure output of escape
                                       ! character.

 The CHAR(int) intrinsic function is used to form either printing or
 nonprinting characters using the corresponding integer from the ASCII
 table.


 649. Problem with Character*(*) Length Specifier in FORTRAN

 Product Version(s): 4.00 5.00 | 5.00
 Operating System:   MS-DOS    | OS/2
 Flags: ENDUSER | buglist5.00
 Last Modified: 30-NOV-1990    ArticleIdent: Q67227

 In a Microsoft FORTRAN version 4.00 or 5.00 program, invalid output
 can be generated in a subroutine that accepts a character string with
 the CHARACTER*(*) length specifier. For the error to occur, the
 following conditions must also exist:

 1. There must be at least one initial CALL to a subroutine in which a
    character argument is passed.

 2. The CALL to the subroutine that produces invalid output must
    contain, as its first actual argument, a reference to a function.
    This function must accept a character argument. The length of the
    character argument it accepts must be different than the length of
    the character argument passed as the second actual argument in the
    faulty subroutine.

    Note: In this situation, the second formal argument to the
    subroutine, which is typed as CHARACTER*(*), assumes the length of
    the character string from the function reference, instead of the
    correct length.

 The following example produces the invalid output:

       integer*4 IFUN
       character*1 C1
       character*2 C2
        c2='xy'
        call sub1(c1)
        call sub2(IFUN(c1),c2)    ! line 7
       end
 C
       subroutine sub1(x)
        character *(*) x
       end
 C
       subroutine sub2(i,c)
        character *(*) c
        integer i
        print*,c             ! prints "x" instead of "xy"
        print*,len(c)        ! prints 1 instead of 2
       end
 C
       integer*4 function IFUN(c)
        character*(*) c
        IFUN=0
       end

 The actual length being returned for c2 is the length of c1.

 In Microsoft FORTRAN version 5.00, the compiler leaves out an assembly
 code line passing the length of the character string to the second
 subroutine. Versions 4.1 and 4.01 retain this assembly code and work
 correctly. Version 4.00 has many differences at the assembly level
 and nothing can be concluded.

 Note: The /Od switch does not affect this code.

 A possible solution would be to replace line 7 with one of
 the following:

 1. Switch the order of the following arguments:

       call sub2(c2,IFUN(c1))

 2. Use an intermediate variable, as follows:

       j=IFUN(c1)
       call sub2(j,c2)

 Microsoft has confirmed this to be a problem in FORTRAN
 versions 4.00 and 5.00. We are researching this problem and
 will post new information here as it becomes available.


 650. Extending a Common Block with an EQUIVALENCE Statement

 Product Version(s): 4.00 4.01 4.10 5.00 | 4.10 5.00
 Operating System:   MS-DOS              | OS/2
 Flags: ENDUSER |
 Last Modified: 30-NOV-1990    ArticleIdent: Q67229

 An EQUIVALENCE statement can be used to extend a common block size by
 EQUIVALENCing the last element of a common block with the first element
 of an array that is not in a common block. This is demonstrated
 in the code below.

 This article expands upon the information in the EQUIVALENCE statement
 section of the "Microsoft FORTRAN Reference" manual, which discusses
 extending common blocks found.

 The following code fragment shows a common block being extended from
 4 bytes to 800 bytes in length.

 C ***** FORTRAN program fragment *****

       REAL*4 VAR, A(200)
       COMMON /TEST/ VAR
       EQUIVALENCE (VAR, A(1))

 In this fragment, the common block TEST is initially 4 bytes in
 length. The equivalence statement specifies that VAR and A(1) will
 share the same location in memory. Because all of A's elements are
 contiguous in memory, the common block TEST is extended to be 200 x 4
 or 800 bytes in length. This is shown graphically below:

    |01|02|03|04|05|06|07|08|09|0A|0B|0C|0D|0E|0F|10|
    |------------------------------------------------
    |....VAR....|
    |------------------------------------------------
    |....A(1)...|....A(2)...|....A(3)...|....A(4)...|
    |------------------------------------------------
    |<-- Beginning address of common block TEST

 The guidelines listed below must be followed when using EQUIVALENCE to
 extend a common block's length:

 1. A common block may only be extended by adding elements to the end
    of the common block. An EQUIVALENCE operation cannot add elements
    that precede the common block as in the following example:

 C ***** FORTRAN program fragment *****

       REAL*4 VAR, A(200)
       COMMON /TEST/ VAR
       EQUIVALENCE (VAR, A(2))

    Here VAR and A(2) will share the same memory location. Because A(1)
    precedes A(2) in memory, it will also precede VAR, which is the
    beginning of the common block. This is called extending a common
    block forward and is shown graphically below:

       |??|??|??|??|01|02|03|04|05|06|07|08|09|0A|0B|0C|0D|0E|0F|10
       ------------|------------------------------------------------
       ............|....VAR....|
       ------------|------------------------------------------------
       |....A(1)...|....A(2)...|....A(3)...|....A(4)...|....A(5)...
       ------------|------------------------------------------------
       ............|<-- Beginning address of common block TEST

    The following error is generated when the code listed above is
    compiled:

       F2320: A : EQUIVALENCE : extends common block TEST forward

 2. The ANSI FORTRAN 77 Standard states that a NAMED common block must
    be of the same size in all program units of an executable program
    in which it appears. For this reason, when a NAMED common block is
    extended, every subsequent subprogram accessing the common block
    must declare it according to its new size. For example, in the
    code below, a NAMED common block is again declared with one REAL*4
    element and then EQUIVALENCEd with a 200 element REAL*4 array. In
    the subroutine, the common block is then declared with its new size
    of 200 elements:

 C ***** FORTRAN program fragment *****

       PROGRAM main
       REAL*4 VAR, A(200)
       COMMON /TEST/ VAR
       EQUIVALENCE (VAR, A(1))
       CALL sub()
       .
       .
       END

       SUBROUTINE sub ()
       REAL*4 B
       COMMON /TEST/ B(200)
       .
       .
       RETURN
       END

    However, FORTRAN 5.00 will allow a NAMED common block to have
    different sizes in subprogram units. In this situation, the compiler
    generates the following warning:

       F4329: TEST : COMMON : size changed

    If the /4Ys compile option or $STRICT metacommand is used with
    FORTRAN 5.00, or if the program is compiled with FORTRAN 4.x, the
    error

       F2323: TEST : COMMON : size changed

    is generated when a NAMED common block's size is changed in a
    subprogram.


 651. No Error on Out-of-Range Read of INTEGER*1 Variable

 Product Version(s): 4.00 4.01 4.10 5.00 | 4.10 5.00
 Operating System:   MS-DOS              | OS/2
 Flags: ENDUSER | buglist4.x buglist5.00
 Last Modified: 30-NOV-1990    ArticleIdent: Q67230

 With a program compiled under Microsoft FORTRAN, reading a value that
 is less than -128 or more than +127 into an INTEGER*1 variable can
 fail to produce the expected error.

 The compiler should generate the following error:

    run-time error F6100:  READ
    -INTEGER overflow on input

 The following code reproduces the problem:

       integer*1 i
 10    read (*,*) i
       write (*,*) i
       goto 10
       end

 Entering the following values produces the corresponding results:

     0-127     Returns proper value

     128-255   Causes a Run-Time Error (RTE) as expected

     256-383   Returns value minus 256 (should cause an RTE)

     384-511   Causes an RTE

 This cycle repeats every 128 values.

 It appears that the run-time error management routine is inspecting
 the first byte of the input value to see if it is within range, and
 ignoring the remaining bytes. The following is an example:

     127 =  01111111               Returns the value 127

     128 =  10000000               Returns Run-time error

     255 =  00000000 11111111      Returns Run-time error

     256 =  00000001 00000000      Returns the value 0

 Thus, if the first byte is out of range, the program will correctly
 generate the error. However, if the first byte is in range, the
 program ignores all other bytes, fails to produce the error, and
 returns the value of the first byte. The /4Yb and $DEBUG metacommand
 do not affect the results.

 Microsoft has confirmed this to be a problem in FORTRAN versions 4.xx
 and 5.00. We are researching this problem and will post new
 information here as it becomes available.


 652. F1001: XX-2, Line 539, Allocating 43 Arrays in One Statement

 Product Version(s): 5.00   | 5.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | buglist5.00
 Last Modified: 30-NOV-1990    ArticleIdent: Q67231

 When you allocate 43 or more arrays with one ALLOCATE statement in
 Microsoft FORTRAN version 5.00, the following error is produced, where
 XX = ASCII characters 2 and 254:

    fatal error F1001:  Internal Compiler Error
    (compiler file "XX-2," line 539)

 Solution
 --------

 Breaking the ALLOCATE statement into two separate statements
 eliminates the error.

 The size of the arrays has no effect on the error. If only 42 arrays
 are defined and allocated, the error is not generated.

 The following code reproduces the internal compiler error:

       INTEGER
      + a1  [ALLOCATABLE] (:), a2  [ALLOCATABLE] (:),
      + a3  [ALLOCATABLE] (:), a4  [ALLOCATABLE] (:),
      + a5  [ALLOCATABLE] (:), a6  [ALLOCATABLE] (:),
      + a7  [ALLOCATABLE] (:), a8  [ALLOCATABLE] (:),
      + a9  [ALLOCATABLE] (:), a10 [ALLOCATABLE] (:),
      + a11 [ALLOCATABLE] (:), a12 [ALLOCATABLE] (:),
      + a13 [ALLOCATABLE] (:), a14 [ALLOCATABLE] (:),
      + a15 [ALLOCATABLE] (:), a16 [ALLOCATABLE] (:),
      + a17 [ALLOCATABLE] (:), a18 [ALLOCATABLE] (:),
      + a19 [ALLOCATABLE] (:), a20 [ALLOCATABLE] (:),
      + a21 [ALLOCATABLE] (:), a22 [ALLOCATABLE] (:),
      + a23 [ALLOCATABLE] (:), a24 [ALLOCATABLE] (:),
      + a25 [ALLOCATABLE] (:), a26 [ALLOCATABLE] (:),
      + a27 [ALLOCATABLE] (:), a28 [ALLOCATABLE] (:),
      + a29 [ALLOCATABLE] (:), a30 [ALLOCATABLE] (:),
      + a31 [ALLOCATABLE] (:), a32 [ALLOCATABLE] (:),
      + a33 [ALLOCATABLE] (:), a34 [ALLOCATABLE] (:),
      + a35 [ALLOCATABLE] (:), a36 [ALLOCATABLE] (:),
      + a37 [ALLOCATABLE] (:), a38 [ALLOCATABLE] (:),
      + a39 [ALLOCATABLE] (:), a40 [ALLOCATABLE] (:),
      + a41 [ALLOCATABLE] (:), a42 [ALLOCATABLE] (:),
      + a43 [ALLOCATABLE] (:)

       ALLOCATE (
      + a1  (1), a2  (1), a3  (1), a4  (1), a5  (1),
      + a6  (1), a7  (1), a8  (1), a9  (1), a10 (1),
      + a11 (1), a12 (1), a13 (1), a14 (1), a15 (1),
      + a16 (1), a17 (1), a18 (1), a19 (1), a20 (1),
      + a21 (1), a22 (1), a23 (1), a24 (1), a25 (1),
      + a26 (1), a27 (1), a28 (1), a29 (1), a30 (1),
      + a31 (1), a32 (1), a33 (1), a34 (1), a35 (1),
      + a36 (1), a37 (1), a38 (1), a39 (1), a40 (1),
      + a41 (1), a42 (1), a43 (1))
       END

 To avoid this error, limit each ALLOCATE statement to less than 43
 arrays.

 Microsoft has confirmed this to be a problem in FORTRAN version 5.00.
 We are researching this problem and will post new information here as
 it becomes available.


 653. EXIT Statement Not Flagged as Nonstandard Statement

 Product Version(s): 5.00   | 5.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified: 30-NOV-1990    ArticleIdent: Q67232

 The EXIT statement, implemented in Microsoft FORTRAN version 5.00, is
 documented as an extension to the ANSI FORTRAN 77 standard (it appears
 in blue type in the "Microsoft FORTRAN Reference" manual). In
 addition, the EXIT statement does not appear in the list of IBM SAA
 and VAX extensions on pages 330-332 of the "Microsoft FORTRAN
 Reference" manual. For these reasons, the EXIT statement should
 generate the following error

    F2732 EXIT:  nonstandard statement

 when a FORTRAN 5.00 program is compiled with the $STRICT metacommand,
 or the /4Ys, /4Yi, or /4Yv compile option. This error is not generated
 under any circumstances.

 Microsoft has confirmed this to be a problem in FORTRAN version 5.00.
 We are researching this problem and will post new information here as
 it becomes available.


 654. Opening More than 123 Files Causes Error F6415 or F6417

 Product Version(s): 5.00   | 5.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | buglist5.00
 Last Modified:  4-DEC-1990    ArticleIdent: Q67318

 After you increase the limit for the maximum number of open files to
 any number above 128, as discussed on pages 405 and 406 of the
 "Microsoft FORTRAN Reference" manual, the run-time error

    F6415: OPEN(file name)
    - file already exists

 or the run-time error

      F6417: OPEN(file name)
      - too many open files

 will be produced. FORTRAN generates these errors when you attempt to
 open more than 123 files at one time. Because FORTRAN reserves five
 file handles for its own use, the error occurs when the 129th file
 handle is requested. However, page 405 of the "Microsoft FORTRAN
 Reference" manual states that the maximum limit of open files is 256.

 Microsoft has confirmed this to be a problem in FORTRAN version 5.00.
 We are researching this problem and will post new information here as
 it becomes available.

 If 123 files are already open and the 124th file does not exist, the
 following error will be generated:

    F6415: OPEN(file name)
    - file already exists

 If the 124th file to be opened exists, the following error will
 be generated:

    F6417: OPEN(file name)
    - too many open files

 On some systems, only 122 files can be opened; while on other systems
 if the 124th file does not exist, it is created before the error
 message is generated.


 655. F1001: omf_ms.c:1.118, line 2785; Common Block Too Large

 Product Version(s): 5.00   | 5.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | buglist5.00
 Last Modified: 10-DEC-1990    ArticleIdent: Q67420

 When the data in a COMMON block exceeds 45,940,736 (44,864K) bytes,
 the Microsoft FORTRAN version 5.00 compiler generates the following
 error:

    fatal error F1001: Internal Compiler Error
    (compiler file '@(#)omf_ms.c:1.118', line 2785)

 Microsoft has confirmed this to be a problem in FORTRAN version 5.00.
 We are researching this problem and will post new information here as
 it becomes available.

 The following code generates this error:

        INTEGER*1 A(45940737)
        COMMON  A
        END

 Any combination of data that adds up to more then 44,864K bytes will
 generate this error. The COMMON block can be named or unnamed.

 The following is another code sample that generates this error:

        REAL*4 A(3388,3388)
        INTEGER*1 B(26561)
        COMMON /TEST/ A,B
        END

 FORTRAN versions 4.x do not produce this error; instead, versions 4.x
 under DOS cause the following error:

    fatal error F1039: unrecoverable heap overflow in Pass 3

 FORTRAN 4.10 under OS/2 produces no compiler errors with the above
 code.

 Although using a slightly smaller amount of data allows compilation,
 using this much data in a single module will violate other limitations
 of the FORTRAN compiler and linker. For example, decreasing the size
 of the INTEGER array in the above code sample allows compilation with
 FORTRAN 5.00, but generates the following linker error:

    fatal error L1047: too many group, segment, and class names in
    one module

 The only practical solution is to decrease the size of the arrays
 significantly. The largest quantity of data that does not violate
 the limits on the number of group, segment, and class names is
 15,990,784 bytes, or 244 segments of 64K bytes per segment.


 656. Adjustable-Size Arrays Can Hang Machine in FORTRAN 5.00

 Product Version(s): 5.00   | 5.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | buglist5.00
 Last Modified: 15-FEB-1991    ArticleIdent: Q67515

 Using the Microsoft FORTRAN 5.00 compiler on a program that contains
 an adjustable size array without the array being a formal argument to
 a subroutine can cause the machine to hang during compilation under
 DOS.

 This code will cause the compiler to generate an internal compiler error
 when compiling under OS/2.

 The compiler should generate the following error messages.

 In a Subroutine
 ---------------

 F2841:  adjustable-size array: not reference argument

 In a Main Program
 -----------------

 F2339:  adjustable-size array not in subprogram

 To eliminate the problem, include the array as an argument to the
 subroutine or declare it as ALLOCATABLE and allocate it. Page 145 of
 the "Microsoft FORTRAN Reference" manual explains how adjustable-sized
 arrays must be formal arguments to the program unit in which they
 appear. Allocatable arrays, however, must not be formal arguments.
 They are discussed on pages 25 and 113 of the "Microsoft FORTRAN
 Reference" manual. Versions 4.x of the compiler correctly report the
 error.

 Microsoft has confirmed this to be a problem in FORTRAN version 5.00.
 We are researching this problem and will post new information here as
 it becomes available.

 The following code reproduces the problem in a subroutine:

        SUBROUTINE a (b,c)
        DIMENSION b(1,1),d(c,1,1)
        e=1
        d(e,e,e) = d(1,1,1)+b(1,1)*d(1,1,1)
        END

 The error is dependent on both of the assignment statements and the
 arithmetic in the second statement. For example, changing the
 left-hand side of the equation in the second assignment statement to
 "d(1,1,1)" instead of "d(e,e,e)" will generate the correct error.

 The following code reproduces the problem in a main program:

        DIMENSION b(1,1),d(c,1,1)
        e=1
        d(e,e,e) = d(1,1,1)+b(1,1)*d(1,1,1)
        END

 In the main program, the following error is generated before
 causing a Protection Violation or hanging the machine:

    F2339: Adjustable-size array not in subprogram

 If an adjustable-size array is desired in the main program, declare
 the array as ALLOCATABLE and then allocate it using variables to
 establish the dimensions.


 657. Structure Element in OPEN Causes Protection Violation

 Product Version(s): 5.00
 Operating System:   OS/2
 Flags: ENDUSER | buglist5.00
 Last Modified:  9-JAN-1991    ArticleIdent: Q67615

 Using an element of a structure as a filename in an OPEN statement
 generates a protection violation when you compile under the OS/2
 operating system when you use Microsoft FORTRAN version 5.00. To work
 around this problem, assign the value of this member to a temporary
 variable and use this with your OPEN statement.

 There seems to be no problem compiling under DOS, and programs with
 this code appear to function correctly. Also, programs using this
 method of opening files, which are compiled under DOS but linked for use
 under OS/2, appear to run correctly under OS/2.

 Microsoft has confirmed this to be a problem in the FORTRAN compiler
 version 5.00. We are researching this problem and will post new
 information here as it becomes available.

 The program below illustrates this problem:

       program test

       structure /io/
         character* 12 name
       end structure

       record /io/ ioinst

       ioinst.name = 'test.dat'

       open (10, file=ioinst.name)

       end

 To work around this problem, change the program to the following:

       program test

       structure /io/
         character* 12 name
       end structure
       character* 12 tmp

       record /io/ ioinst

       ioinst.name = 'test.dat'

       tmp = ioinst.name
       open (10, file=tmp)

       end

 Another possible solution to this problem is to compile the program
 under DOS and link for use under OS/2.


 658. Problem Reading Direct-Access File When RECL > BLOCKSIZE

 Product Version(s): 4.01 4.10 5.00 | 4.10 5.00
 Operating System:   MS-DOS         | OS/2
 Flags: ENDUSER | buglist4.01 buglist4.10 buglist5.00
 Last Modified:  4-JAN-1991    ArticleIdent: Q68030

 In Microsoft FORTRAN versions 4.01 through 5.00, when a direct-access
 file is opened with a BLOCKSIZE set to a value that is less than the
 RECL (record length), incorrect records may be read from the file.

 The easiest way to avoid this problem is to always use a record length
 that is less than or equal to the BLOCKSIZE (the default BLOCKSIZE is
 1024). Other possible solutions are listed below.

 Microsoft has confirmed this to be a problem in FORTRAN versions 4.01,
 4.10, and 5.00. We are researching this problem and will post new
 information here as it becomes available.

 The following code demonstrates this problem:

       CHARACTER*514 ALINE
       CHARACTER*10  SHORT

       OPEN(9,ACCESS='DIRECT',RECL=514,
      +FORM='FORMATTED', BLOCKSIZE=512)

 C Note that the BLOCKSIZE is smaller than the record length

       DO 10 J=1,4                        ! Create a file to read.
          ALINE = 'TEST '// CHAR(#30+J)   ! Put the record number
          WRITE(9,30,REC=J) ALINE         ! in each record.
 10    CONTINUE

 C This is the start of the READ sequence where the problem occurs.

       READ(9,30,REC=3) SHORT   ! This is the partial read
                                ! into record 3.

       DO 20 I=1,4
          READ(9,30,REC=I) ALINE
          WRITE(*,*) ALINE
 20    CONTINUE
 30    FORMAT(A)
       END

 The first DO-loop in the program constructs a four record
 direct-access scratch file. This is followed by a partial read of
 record 3 from the file. The following DO-loop reads the file from
 record 1 to record 4 and outputs the result to the screen.

 The program output indicates that the READ statement in the DO-loop
 improperly accesses the information in the scratch file. Because the
 RECL (record length) exceeds the BLOCKSIZE (buffer size), each READ
 forces the buffer to be filled twice. The extra information is not
 being flushed from the buffer, and is incorrectly read into the
 variable ALINE on every READ after the initial partial READ of record
 3.

 Some ways to avoid this problem:

 1. Make sure that RECL (record length) is less than BLOCKSIZE.

 2. Access the direct-access file with a variable or group of variables
    with a length in bytes that matches the record length, thus
    avoiding partial access to a record.

 3. Use a REWIND statement following any partial access to a record.
    This realigns the file pointer to the beginning of the file
    (BACKSPACE does not appear to solve the problem).

 This problem does not occur in FORTRAN versions 4.00 and 4.00a;
 however, it does occur in versions 4.01, 4.10, and 5.00.


 659. SELECT CASE with /4I2 Creates Oversized .OBJ Module

 Product Version(s): 5.00   | 5.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | buglist5.00
 Last Modified: 10-JAN-1991    ArticleIdent: Q68104

 The FORTRAN 5.00 compiler can create greatly oversized object modules
 when a program that uses the SELECT CASE statement is compiled with
 the /4I2 switch in the DOS environment. When the same program is
 compiled under OS/2, the compiler appears to hang.

 Because of the size of the object module, the following warnings are
 also generated when you compile with the /4I2 switch:

    F4063: function too large for post-optimizer
    L4020: code segment size exceeds 65500

 The resulting executable can cause the machine to hang.

 Microsoft has confirmed this to be a problem in FORTRAN version 5.00.
 We are researching the problem and will post new information here as
 it becomes available.

 When the following sample program is compiled with the /4I2 compiler
 switch under DOS, the program produces an object file of over 160,000
 bytes. Without the /4I2 switch, an object module of several hundred
 bytes is generated. An assembly listing of the program shows that the
 compiler generates repetitive lines of invalid code.

 Program
 _______

       select case (i)
              case (  :-3)
              case (-2: 0)
              case ( 1 )
              case ( 2 )
       end select
       end

 To avoid this problem, do not use the /4I2 compiler switch when you
 are compiling programs that use the SELECT CASE...END SELECT
 statement.


 660. Problem Writing Array of Structure Variables with F1.EXE Patch

 Product Version(s): 5.00   | 5.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | buglist5.00
 Last Modified: 28-JAN-1991    ArticleIdent: Q68528

 Programs compiled with FORTRAN 5.00 using the patched version of
 F1.EXE or the patched High-Capacity Compiler F1L.EXE can generate
 incorrect output when you write an array of structure variables.

 If you use the patched High-Capacity Compiler F1L.EXE with programs
 containing such code, and link for OS/2, you may generate the
 following error:

    Error L2002: fixup overflow at 13 in segment _DATA
    pos: 15F Record type: 9C
    frm seg NULL, tgt seg_BSS, tgt offset E05

 The resulting executable will not run.

 These errors do not occur when you use the unpatched versions of the
 F1.EXE or the High-Capacity Compiler F1L.EXE.

 Microsoft has confirmed this to be a problem in FORTRAN version 5.00.
 We are researching this problem and will post new information here as
 it becomes available.

 The F1.EXE patch is used to correct, among other things, the error:

    F1001: Internal Compiler Error
           compiler file omf_ms.c:1.118, line 1093

 This error often results when I/O operations are performed on elements
 of a structure after that structure has been passed to a subroutine.

 The High-Capacity Compiler F1L.EXE is an alternate form of the first
 pass of the compiler. It should be used to compile programs that
 receive the error:

    F1901: program too large for memory

 The following program illustrates the problem.

       structure / rec /
        character*12 num
       end structure

       record / rec / allrec(3)

       allrec(1).num= 'one'
       allrec(2).num= 'two'
       allrec(3).num= 'three'

 10    format(' ',a12)
       do 20 i=1, 3
        write(*,10) allrec(i).num
 20    continue
       end

 The program should produce the output:

    one
    two
    three

 Instead, when the program is compiled using the patched F1.EXE and
 linked for DOS or OS/2, it produces the following output:

    one
    one
    one

 When the program is compiled with the patched High Capacity Compiler
 F1L.EXE and linked for OS/2, the linker produces the fixup overflow
 error and the resulting executable is nonfunctional. When the program
 is linked for DOS after using the patched High Capacity Compiler, it
 can generate three repeated lines of random text output. It may also
 produce three blank lines of output.

 Workaround
 ----------

 A workaround to this problem is as follows:

 1. Declare a temporary variable.

 2. Assign the structure element to the temporary variable.

 3. Then use the temporary variable in all I/O operations.

 Note: This is also a suggested workaround to problems solved by using
 the F1.EXE patch.

 Sample
 ------

 For example:

       structure / rec /
         character*12 num
       end structure

       record / rec / allrec(3)

       character*12 temp           ! 1)

       allrec(1).num= 'one'
       allrec(2).num= 'two'
       allrec(3).num= 'three'

 10    format(' ',a12)
       do 20 i=1, 3
        temp=allrec(i).num         ! 2)
        write(*,10) temp           ! 3)
 20    continue
       end


 661. Incorrect Output with Element of Structure in CHAR Function

 Product Version(s):
 Operating System:   5.00   | 5.00
 Flags: MS-DOS | OS/2
 Last Modified:  7-FEB-1991    ArticleIdent: Q69002
 ENDUSER | buglist5.00

 In FORTRAN 5.00, a program using the CHAR intrinsic function on a
 structure element within a WRITE or PRINT statement can produce
 erroneous output when executed under DOS, or result in a protection
 violation when executed under OS/2.

 To avoid these problems, remove the intrinsic function from the WRITE
 or PRINT statement by assigning the result of the CHAR intrinsic
 function to a temporary variable, and then use this variable in the
 output statement.

 Microsoft has confirmed this to be a problem in FORTRAN version 5.00.
 We are researching this problem and will post new information here as
 it becomes available.

 The following example reproduces the problem:

        structure /a/
          integer*2 i
        end structure

        record /a/ name
        name.i=97                   ! ASCII lowercase a
        write(*,*) char(name.i)
        end

 1. When the above program is linked for DOS, the resulting executable
    prints the wrong character or no character at all.

 2. When it is linked for OS/2, the resulting executable generates a
    protection violation during runtime.

 3. When it is compiled under DOS with the patched version of F1.EXE
    (used to correct several problems with structures and NAMELIST
    statements) and linked for either DOS or OS/2, the executable
    generates the correct results.

 4. When it is compiled under OS/2 with the patched version of F1.EXE,
    a protection violation is generated during compilation in the F2.EXE
    pass of the compiler.

 One possible solution is to assign the result of the CHAR intrinsic
 function to a temporary variable as illustrated by the following
 example:

        structure /a/
          integer*2 i
        end structure

        character c
        record /a/ name
        name.i=97              ! ASCII lowercase a

        c=char(name.i)
        write(*,*) c
        end


 662. Problem Directing Listing and Object Files to a Directory

 Product Version(s): 5.00   | 5.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | docerr
 Last Modified:  7-FEB-1991    ArticleIdent: Q69040

 The listing options and object file naming option used by FORTRAN 5.00
 do not function as documented in the "Microsoft FORTRAN Reference"
 manual. Compiling more than one source file at a time fails to create
 listing or object files in the specified path for every source file
 listed after the option on the command line. The first listing or
 object file is created in the specified path. The remaining listing or
 object files are either created in the current directory or not
 created at all.

 Microsoft has confirmed this to be a problem in FORTRAN version 5.00.
 We are researching this problem and will post new information here as
 it becomes available.

 If you compile more than one source file at a time with one of the
 following compiler switches set to a path other than the current
 directory, you will create the first listing or object file in the
 specified path. The listing or object files for the other source files
 are created in the current directory.

    Option                    File Type
    ------                    ---------

    /Fs[[listfile]]           Source Listing
    /Fc[[listfile]]           Combined Source-Object Listing
    /Fo[[objfile]]            Object

 If you compile more than one source file at a time with one of the
 following compiler switches set to a path other than the current
 directory, you will create the first listing in the specified path.
 Listings for the other source files are not created.

    Option                    File Type
    ------                    ---------

    /Fa[[listfile]]           Assembly Listing
    /Fl[[listfile]]           Object Listing

 Using Microsoft FORTRAN 5.00 to compile more than one source file at a
 time with the listing options or object file naming option set to a
 path other than the current directory should create listing or object
 files using the specified path for every source file listed after the
 option on the command line (see pages 338-342 of the "Microsoft
 FORTRAN Reference" manual).

 This problem does not occur in FORTRAN versions 4.x.

 The following command line illustrates the problem:

    FL /FsD:\LISTINGS\ A.FOR B.FOR C.FOR

 If the current directory is D:\FORTRAN and the source files are A.FOR,
 B.FOR, and C.FOR, then the source listings for file A.FOR will be
 generated in the D:\LISTINGS directory and the source listings for
 files B.FOR and C.FOR will be generated in the D:\FORTRAN directory.

 To have all of the source listings in the D:\LISTINGS directory,
 compile with the following command line:

    FL /FsD:\LISTINGS\ A.for /FsD:\LISTINGS\ B.FOR /FsD:\LISTINGS\ C.FOR


 663. NAMELIST in Internal READ Yields Error F1901 in FORTRAN

 Product Version(s): 5.00   | 5.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | buglist5.00
 Last Modified: 12-FEB-1991    ArticleIdent: Q69071

 Using FORTRAN 5.OO, under DOS, to compile a program that uses an
 internal READ to read from a character variable into a NAMELIST
 generates the error:

    F1901:  Program too large for memory

 Under OS/2, a protection violation is generated during compilation.

 Using the high-capacity compiler F1L.EXE (normally used to correct the
 above error) can result in hanging the machine during compilation under
 DOS.

 An internal READ cannot be used in FORTRAN 5.00 to read in a NAMELIST.
 One solution is to put the NAMELIST data into a external file, either
 before or during program execution.

 Microsoft has confirmed this to be a problem in FORTRAN version 5.00.
 We are researching this problem and will post new information here as
 it becomes available.

 The following code illustrates the problem:

       character*21 test /' &in x=1 y=5 z=10 /'/
        namelist /in/ x,y,z
        read(test,in)
       end

 When compiling this code under DOS using the high-capacity compiler,
 the machine will hang. When compiling this code under OS/2 using the
 high-capacity compiler, a protection violation is generated. The
 high-capacity compiler F1L.EXE is a replacement for the first pass of
 the compiler, and is used to correct the error:

    F1901:  Program too large for memory

 The patched versions of F1.EXE and F1L.EXE, (used to correct problems
 with NAMELIST), produce the same results as F1.EXE and F1L.EXE
 respectively.

 One solution is to read in the NAMELIST data from an external file
 rather than an internal file:

 c test.for
        open(8,file='test.dat')
        namelist /in/ x,y,z
        read(8,in)
        write(*,in)
        close(8)
        end

 data file test.dat:

 &in
 x=1
 y=5
 z=10
 /
 c

 Alternatively, a scratch file can be created in which to temporarily
 store the NAMELIST data:

        character*21 test /' &in x=1 y=5 z=10 /'/
        namelist /in/ x,y,z

        open(8)
        write(8,*) test
        rewind(8)
        read(8,in)
        write(*,in)
        close(8)
        end


 664. Calling DOS and BIOS Interrupts Using FORTRAN 5.00 and MASM

 Product Version(s): 5.00
 Operating System:   MS-DOS
 Flags: ENDUSER | softlib INTERPT.ARC q68908
 Last Modified: 13-FEB-1991    ArticleIdent: Q69152

 DOS and BIOS interrupts can be accessed in FORTRAN without the
 functions INTDOS and INTDOSX. Two assembly code routines INTERRUPT and
 INTERRUPTX are available in the Software/Data Library that allow
 access to most interrupts including interrupt number 21. In addition,
 an INCLUDE file and two FORTRAN sample programs are included in the
 Software/Data Library article that demonstrate how to use the
 INTERRUPT and INTERRUPTX function calls.

 This file (FORINTER) can be found in the Software/Data Library by
 searching for the filename FORINTER, the Q number of this article, OR
 S12908.

 FORINTER was archived using the PKware file-compression utility.

 To utilize the INTERRUPT AND INTERRUPTX functions, the statement

    INCLUDE 'INTERRPT.INC'

 must be contained at the top of the source file making the call.
 The two statement functions documented at the end of the
 INTERRPT.INC file must be uncommented and added to the source code
 of any program, function, or subroutine block where the assembly
 procedures are called. These statement functions must appear before
 any executable statements. INTERRUPT.OBJ must be linked with the
 object file produced from compiling the main program.

 *********************
 INTERRPT.INC : include file for INTERRUPT and INTERRUPTX.
 This file includes the INTERFACE to the assembler routines and the
 register structures needed for these routines.

 Copy these statement functions after your other declarations but
 before other executable statements in the program, subroutine, or
 function in which you call INTERRUPT or INTERRUPTX

       gethibyte (dataword) = dataword / 256
       getlobyte (dataword) = iand(dataword , 255)
 *********************

 *********************
 INTERRPT.ASM The assembler source listing of the INTERRUPT and
 INTERRUPTX routines.
 ***************

 ***************
 INT.FOR      A sample program which uses the INT 21, function 2A
 hex to get the system date.
 ***************

 ***************
 INTX.FOR:  A sample program which uses the INT 21, function 41 hex
 to delete a file.

 This example uses the segment registers.

 ***************


 665. Key Entry Routines in MASM with FORTRAN 5.00

 Product Version(s): 5.00   | 5.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | softlib q68703
 Last Modified: 12-FEB-1991    ArticleIdent: Q69153

 Two examples of simple key fetch routines written in the Microsoft
 Macro Assembler (MASM) version 5.10 for use with Microsoft FORTRAN are
 contained within the Software/Data Library. These routines use DOS
 interrupts and do not work under OS/2.

 This file (FORGETCH) can be found in the Software/Data Library by
 searching for the filename FORGETCH, the Q number of this article, or
 S12907.

 FORGETCH was archived using the PKware file-compression utility.

 Example A contains a function that, when called, waits for a
 keystroke and then passes back the keystroke to the FORTRAN calling
 program. This can be used to get single keystroke information from the
 user without requiring use of the ENTER key.

 Example B contains a function that checks to see if a keystroke has
 been previously entered. This function does not wait for the user to
 enter a character, but reports if a character has been entered. Once
 again, the user does not need to press the ENTER key for single-key
 data to be accepted.

 This program was not designed for redirected standard input.
 Furthermore, the interface routine is currently set up to only flag
 that a function or ALT+<KEY> sequence has been entered, and to print a
 message accordingly.


 666. ENTRY Statement Causes F2836: Statement Out of Order Error

 Product Version(s):
 Operating System:   4.00 4.01 4.10 5.00 | 4.10 5.00
 Flags: MS-DOS              | OS/2
 Last Modified: 13-FEB-1991    ArticleIdent: Q69188
 ENDUSER |

 Using the Microsoft FORTRAN compiler on code containing a subroutine
 that has an ENTRY statement preceding specification statements, type
 statements, implicit statements, or parameter statements will generate
 the following error:

    F2836: Statement Out of Order

 A subroutine that has an ENTRY statement preceding Statement Function
 statements will generate the following error:

    F2515: left side of assignment illegal

 A subroutine that has an ENTRY statement preceding the $LARGE or the
 $NOTLARGE metacommand (used with or without arguments) will generate
 the following respective errors:

    F2021: $LARGE illegal in executable statements
    F2021: $NOTLARGE illegal in executable statements

 Placing these statements before the ENTRY statement will not generate
 the errors.

 Microsoft has confirmed this to be a problem in FORTRAN versions 4.x
 and 5.00. We are researching this problem and will post new
 information here as it becomes available.

 The ENTRY statement on pages 162-163 of the "Microsoft FORTRAN
 Reference" manual specifies an entry point to a subroutine or
 external function.

 According to the Order of Statements chart in the "Microsoft FORTRAN
 Reference" manual on page 47, figure 2.1, the ENTRY statement should
 be able to appear before or after all statements inside a BLOCK DATA,
 FUNCTION, PROGRAM, or SUBROUTINE block.

 The following program, which uses the ENTRY statement and a type
 statement, demonstrates the problem:

       call in
       end

       subroutine sub
       entry in
       integer a
       end

 The error is not generated if the integer type statement is placed
 before the ENTRY statement.


 667. Protection Violation with Array Structure Element in I/O

 Product Version(s): 5.00   | 5.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | buglist 5.00
 Last Modified: 20-FEB-1991    ArticleIdent: Q69405

 A protection violation is generated by the third pass of the Microsoft
 FORTRAN 5.00 compiler in OS/2 when you compile code containing a
 subroutine that uses an array structure element in an I/O statement.

 In DOS, the compiler will generate the error:

    warning F4202: Sub : formal argument : never used
    fatal error F1001: Internal Compiler Error
    (compiler file '@(#)omf_ms.c:1.118', line 1093)
    Contact Microsoft Technical Support

 The F1.EXE patch, which is used to correct structure element I/O
 within subroutines, produces identical errors as the unpatched F1.EXE.

 One possible solution is to assign the structure variable, which is
 passed to the subroutine, to a temporary structure variable, and use
 the temporary structure variable in all I/O statements.

 If you are experiencing invalid output with structure array elements,
 query on "invalid output" for a related article.

 Microsoft has confirmed this to be a problem in FORTRAN version 5.00.
 We are researching this problem and will post new information here as
 it becomes available.

 The following code reproduces the problem:

        structure /t/
           integer j(100)
        end structure
       record /t/ st
       call sub(st)
       end

       subroutine sub(st)
         structure /t/
           integer j(100)
         end structure
       record /t/ st
       write(*,*) st.j    ! line 6
       end

 Accessing an element of the array in line 6 instead of the entire
 array will not result in any error.

 Assigning a temporary structure variable to the structure variable
 that is passed to the subroutine and using the temporary structure
 variable in all I/O statements will prevent these errors.

 The following program illustrates this solution:

         structure /t/
           integer j(100)
         end structure
       record /t/ st
       call sub(st)
       end

       subroutine sub(st)
         structure /t/
           integer j(100)
         end structure
       record /t/ st,temp
       temp=st
       write(*,*) temp.j
       end


 668. Structure Element in Internal File Causes omf_ms.c:1.118

 Product Version(s): 5.00   | 5.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | buglist5.00 err msg
 Last Modified: 20-FEB-1991    ArticleIdent: Q69481

 If you use Microsoft FORTRAN version 5.00 under DOS to compile a
 program that does an Internal READ or WRITE on a structure element,
 the following error may be generated:

    fatal error F1001: Internal Compiler Error
                (compiler file '@(#)omf_ms.c:1.118', line 1093)

 When compiling under OS/2, a protection violation is generated by the
 second pass of the compiler.

 The F1.EXE patch, used to correct structure element I/O within
 subroutines, produces the same errors as the unpatched F1.EXE.

 One way to avoid this error is to assign the element of the structure
 to a temporary variable, and then use this temporary variable in the
 internal READ or WRITE.

 Microsoft has confirmed this to be a problem in FORTRAN version 5.00.
 We are researching this problem and will post new information here as
 it becomes available.

 The following program illustrates this problem:

       structure /a/
       character*5 b
       end structure

       record /a/ c
       real x
       c.b = '10.0'
       read(c.b,'(f5.0)') x
       write(*,*) x
       end

 If you assign the structure element to a temporary variable, as shown
 below, and then use this temporary variable in the internal READ,
 the error will not be generated.

       structure /a/
       character*5 b
       end structure

       record /a/ c
       real x
       character*5 tmp
       c.b = '10.0'
       tmp = c.b
       read(tmp,'(f5.0)') x
       write(*,*) x
       end





 Microsoft Programmer's Work Bench [Development Environment]
 =============================================================================


 1. Using the Features of PWB to Build a Program with Overlays

 Product Version(s): 1.00   | 1.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified: 18-APR-1990    ArticleIdent: Q60050

 A MAKE file built with PWB can be modified (within reason) with the
 user supplied information section. This section, coded as

    # << User_supplied_information >>

 can contain other instructions that PWB (actually NMAKE or NMK) is
 supposed to carry out during the MAKE cycle. All instructions that
 follow this "fence" are not changed by PWB.

 The following instructions detail two implementations of that "fence"
 to allow PWB to build a program that uses overlays.

 While the following steps appear tedious, they are simple in practice.

 Once the changes are made, the only time you need to edit the MAKE
 file directly is to change your overlay structure, or to add or delete
 modules. When adding or deleting modules, you must both edit the
 program list with Make.Edit Program List and modify the commands in
 the user section. If you are only modifying the overlay structure, you
 change just the user section.

 The overlay structure in the example is as follows:

    HELLO.OBJ  (root)
        |
        +----A.OBJ (first  overlay)
        |
        +----B.OBJ (second overlay)

 All of the .OBJs are built from .C files with the same base name.

 1. Use PWB to build the program list in the normal way. This step is
    the same for any new program list.

    a. Start PWB.

    b. Choose Make.Set Program List and specify a new name -- HELLO.MAK
       in this example.

    c. Add HELLO.C, A.C, and B.C to the list. (If you have additional
       .C or .OBJ files, you would add them as well.) When all the
       files are listed, select Set Dependencies.

    d. Choose Options.Build Options and click on the Set Initial
       Build Options button and select DOS EXE.

    e. From Options.Compile Options, select the proper memory model.

    f. From Options.Link Options.Set Debug Options, turn off
       Incremental Link.

    g. From the Options.Browse Options dialog box, turn Generate Browse
       Information on.

    h. Choose Make.Rebuild All to make sure that the program builds
       properly without overlays. If it doesn't, review your work in
       previous steps.

 2. Now that you have a working program list, add the non-PWB
    information to the end.

    a. Choose Make.Clear Program List so that you can edit the MAKE
       file. Attempting to edit the current program list results in the
       message "No-edit file may not be modified."

    b. Choose File.Open to open the MAKE file so you can modify it.

    c. Go to the end of the file and start a blank line.

       Starting in column 1, add the following line:

          # << User_supplied_information >>

       Be sure to enter the line exactly as shown -- spacing is
       significant. This line is a "fence". Everything below the fence
       is yours and is not modified by PWB. Conversely, you should not
       modify anything above the fence because that section belongs to PWB.

    d. Below the fence starting in column one, add the pseudo-target:

          OVERLAID : $(OBJS)

       Be sure it starts column 1. Do not put a blank line after this line.

    e. Copy the command section from the $(PROJ).EXE description block
       to immediately follow the pseudo-target. The command section begins
       on the line following the line that reads

          $(PROJ).exe : $(OBJS)

       and ends at the next blank line. Do not copy the $(PROJ).EXE
       line, and do not leave a blank after the target. After you have
       copied the commands, your file should appear as follows:

          ... PWB section here, unmodified ...

          # << User_supplied_information >>

          OVERLAID : $(OBJS)
          !IF $(DEBUG)                    # copy of commands...
                  $(LRF) @<<$(PROJ).lrf
          $(RT_OBJS: = +^
          ) $(OBJS: = +^
          )
          $@
          ...

    f. Use the following procedure to modify the commands to link an
       overlaid EXE instead of a normal EXE.

       Note: There are two subsections in this section: a debug section
       that starts at the first "!IF $(DEBUG)" and ends at "!ELSE", and
       a release section that starts after the "!ELSE" and ends at the
       first "!ENDIF".

       You need to make the following modifications to both
       subsections.

       i. Delete the line that reads as follows:

             ) $(OBJS: = +^

          After the right parenthesis on the line that moved up, put
          your list of .OBJ files with parentheses to indicate which
          ones go in which overlays. If you need to use more than one
          line for all of your objects, be sure to put a plus sign (+)
          at the end of each line except the last.

      ii. Replace "$@" on the next line with "$(PROJ).EXE".

          In our example,

                 $(LRF) @<<$(PROJ).lrf
             $(RT_OBJS: = +^
             ) $(OBJS: = +^     # delete this line
             )                  # append OBJ list here ...
             $@                 # replace this line with $(PROJ).EXE

          becomes:

                 $(LRF) @<<$(PROJ).lrf
             $(RT_OBJS: = +^
             ) hello.obj +
             (a.obj) +
             (b.obj)
             $(PROJ).exe

          Remember to make the changes in both branches of the !IF
          $(DEBUG).

    g. The last step is to modify the browser database build commands.
       These are the two lines at the very end of the file that begin
       with "$(NMAKEBSC...". PWB adds and deletes these lines in the
       PWB section as you turn browser information on and off.

       Since PWB won't delete and add these lines in the user section,
       enclose them in !IF $(BROWSE)...!ENDIF so they'll be executed
       only when you ask for browse information. You also need to
       delete the "$(NMFLAGS)" macro from the second line to prevent
       infinite NMAKE recursion.

       The following lines

          $(NMAKEBSC1) MAKEFLAGS=
          $(NMAKEBSC2) $(NMFLAGS) -f $(PROJFILE) $(PROJ).bsc

       become:

          !IF $(BROWSE)
              $(NMAKEBSC1) MAKEFLAGS=
              $(NMAKEBSC2) -f $(PROJFILE) $(PROJ).bsc
          !ENDIF

       If you need special NMAKE options for building the browser
       database, just add them where you removed $(NMFLAGS).

 3. Reactivate the MAKE file by selecting Make.Set Program List.

 4. With these changes, if you select Make.Rebuild All, you will still
    get a non-overlaid program because PWB normally builds the first
    target in the MAKE file. To build the overlaid program, modify the
    command line passed to NMAKE so that NMAKE builds your overlay
    target rather than the regular EXE. Select Options.NMAKE Options
    and specify "OVERLAID" as the target by putting it in the NMAKE
    options box, or use Make.Build Target.

 5. With "OVERLAID" in Options.NMAKE Options you can build your program
    by either selecting Make.Rebuild All or Make.Build *.EXE, as usual.
    If you want to build a non-overlaid program, delete "OVERLAID" from
    the NMAKE options box.

    Note that if you use debug options with overlays you will get a
    linker warning L4047. This warning, and the dialog box that says
    that CRT0DAT.ASM can't be found, are normal when building overlaid
    programs for debugging and can be ignored. You can debug the overlaid
    program normally, with full debugging information available.

    This MAKE file behaves almost identically to a regular PWB MAKE
    file. The only differences are that NMAKE options are NOT  passed
    to the browser build unless you add them to the browser build line,
    and that you must edit the user supplied section if you add or
    delete modules from the project.


 2.

 Product Version(s): 1.00   | 1.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | buglist1.00 fixlist1.10 s_c
 Last Modified:  5-FEB-1991    ArticleIdent: Q60392

 TOOLS.PRE is a sample Programmer's WorkBench (PWB) initialization file
 that is installed (and modified) when C 6.00 is installed by running
 the Setup program. On pages 19 and 20 of "Microsoft C: Installing and
 Using the Professional Development System," it states that the
 contents of TOOLS.PRE can be merged with an existing TOOLS.INI file,
 if one exists, or it can be renamed to TOOLS.INI, if there isn't one.
 To work correctly, you must make sure that the contents of this file
 are preceded by a PWB tag (for example, [PWB]) because the supplied
 TOOLS.PRE lacks this tag.

 When merging the PWB 1.00 TOOLS.PRE file into an existing TOOLS.INI
 file, a [PWB] tag should be added just above the area where the file
 is merged. For example:

 [PWB]
   .
   .
   .
   (TOOLS.PRE contents)
   .
   .
   .

 [NEXT-TAG]

 If TOOLS.PRE is being renamed to TOOLS.INI, the tag should be added as
 the first line in the file. In either case, failure to add the tag
 will result in PWB ignoring the initialization information.

 Microsoft has confirmed this to be a problem in PWB version 1.00. This
 problem was corrected in PWB version 1.10.


 3. How to Abort Compilation When Using PWB

 Product Version(s): 1.00   | 1.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | s_c
 Last Modified: 17-JUL-1990    ArticleIdent: Q60500

 Question:

 How do I abort a compile that is in progress when using the
 Programmer's WorkBench (PWB) environment?

 Response:

 Under MS-DOS (or the OS/2 3.x compatibility box), use CTRL+C to abort.

 Under OS/2, use "Arg Meta Compile" to abort a compilation taking place
 in the background.

 The default keystrokes for Arg Meta Compile are ALT+A F9 CTRL+F3.

 You can also create a macro and assign it to a key to abort the
 compile process. Below is a sample macro that you could place in your
 TOOLS.INI file under the [pwb] tag.

    [pwb]
    Abort:=Arg Meta Compile
    Abort:Ctrl+F5

 Note: In either OS/2 or MS-DOS, the ESC key and CTRL+BREAK do not
 abort a compilation.


 4. PWB Makefiles Are Read-Only When Set as Active Program List

 Product Version(s): 1.00   | 1.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified: 25-MAY-1990    ArticleIdent: Q60749

 When you choose the Make.Set Program List option within the
 Programmer's WorkBench (PWB) environment to set a program list for the
 current project, the makefile associated with the current program list
 is marked as read-only and is not editable.

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

 // FOO.C

 #include <stdio.h>
 void main ( void )
 {
    printf ( "Foobar\n" ) ;
 }

 1. Using the above sample program, choose the Make.Set Program List
    menu options and call the program list FOO.MAK.

 2. Save the list.

 3. Choose the File.Open menu, and enter FOO.MAK as the file you want
    to open.

 4. Place your cursor anywhere in the file and press ENTER. You will be
    greeted with the following a pop-up message:

       No-edit file may not be modified.

 If you want to edit the makefile, choose the Make.Clear Program List
 options, and you can edit the makefile as you want.


 5. Why Zero-Length .SBR Files Are Left on the Disk by the PWB

 Product Version(s): 1.00   | 1.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified: 16-JAN-1991    ArticleIdent: Q61056

 When using the Source Browser functionality within the Programmer's
 WorkBench, you can expect to have zero-length .SBR files on your disk.
 This is by design of the PWBRMAKE utility.

 PWBRMAKE.EXE is a utility that converts the .SBR files created by the
 compiler for each program module into a single database file that can
 be read by the Programmer's WorkBench (PWB) Source Browser. The
 resulting Source Browser database file has the extension .BSC.

 When a Source Browser database (a .BSC file) is built from .SBR files,
 the .SBR files are truncated to zero length to save disk space since
 they can be quite large. .SBR files are truncated to zero length,
 rather than being deleted, because PWBRMAKE performs incremental
 updates to the database and, therefore, needs the time and date stamp
 from the files.

 When you rebuild part of your project, new .SBR files are built for
 those modules. Each .SBR file that has not been re-created during a
 build is included as a zero-length file. This tells PWBRMAKE that the
 file has no new contribution to make to the database, so no update of
 that part of the database is required.


 6. Do Not Start Programmer's WorkBench by Typing PWBED

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 11-JUL-1990    ArticleIdent: Q61307

 You cannot start the Programmer's WorkBench by typing PWBED. This is
 incorrect. Type PWB to start the Programmer's WorkBench environment.

 In the REAL MODE directory specified during setup, there will be two
 executables for the PWB, PWB.COM and PWBED.EXE. PWB.COM actually
 spawns PWBED.EXE. If you use PWBED to start the PWB, it will consume
 approximately 500K of memory. By executing a DOS SHELL from within the
 PWB and running CHKDSK, you will notice there is very little memory
 left.

 When you invoke the PWB the correct way (by typing PWB), then shell-
 out and do a CHKDSK, you will see that the PWB has only consumed
 approximately 8K of available memory.

 The PWB appears to work correctly if you invoke it with PWBED.
 However, since it is using so much memory, you will receive memory
 problems, such as "out of memory," "cannot compile," or "cannot
 build." These are caused because there is not enough memory to spawn
 either NMAKE, the compiler, or the linker.


 7. Steps Needed to Make Source Browser Usable

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

 Before using the Browse menu options, you must first define and build
 the database the Source Browser will use. If this database is not
 already built, all options on the Browse menu will be grayed out and
 unusable.

 The following steps must be taken to define a database that is usable
 by the Source Browser menu options:

 1. Generate a program list using the Set Program List command in the
    Make menu. The PWB creates one internally if you do not specify one
    and the program only uses one source file. If a program is larger
    than one source file and a program list is not set, it is
    impossible to generate a Source Browser database.

 2. Choose Browse Options from the Options menu. You must select the
    Generate Browse Information field in the dialog box to create the
    Source Browser database.

 3. Build your program using the Make Menu option. You MUST have a
    successful build (compile AND link) of the program for a Source
    Browser database to be generated.

 The Browse Menu options should now be available for use.

 If, after taking the steps outlined above, the Browse Menu options
 are still unavailable for use, query on the following keywords:

    Browse and Options and Unavailable and Strange and Circumstances
 For printed documentation explaining the setup and use of the Source
 Browser, see Pages 50-52 of "Installing and Using the Professional
 Development System." You can also find information about the Source
 Browser in the online help under Programmer's WorkBench, Using the PWB
 Source Browser.


 8. SYS2070 Issued When Executing PWB.EXE for the First Time

 Product Version(s): 1.00
 Operating System:   OS/2
 Flags: ENDUSER |
 Last Modified: 13-JUN-1990    ArticleIdent: Q61572

 When running the Programmer's WorkBench (PWB) for the first time, the
 following OS/2 system error may be issued:

    Session Title:
    PWBED.EXE

    SYS2070: The system could not demand load the
    application's segment. MSHELP HELPSHRINK is in error.
    For additional detailed information also see message SYS0127

 This system error is caused by the PWB's use of a version of
 MSHELP.DLL that is not as current as the one that was shipped with C
 version 6.00. For the PWB to function correctly, the correct version
 of MSHELP.DLL must be in the LIBPATH.

 The README.DOC on the C version 6.00 Setup/Compiler 1 Disk warns of
 this potential problem, and suggests that QuickHelp (QH) be terminated
 as a background keyboard monitor before Setup is run.

 This problem is usually caused as a result of the Setup program not
 being able to copy its version of MSHELP.DLL over the old version of
 MSHELP.DLL. If another process (most likely a detached session of
 QH.EXE) was accessing this file during the execution of Setup, the
 Setup program will issue a message similar to the following:

    ERROR: Could not create file C:\OS2\DLL\mshelp.dll
    ERROR: File copy failed: A:\the PWB\mshelp.dll to C:\OS2\dll\mshelp.dll

 To solve this problem, take the following steps:

 1. Disable QH as a keyboard monitor:

    a. Press ALT+Q (to invoke QH).

    b. Press O (for the Options menu).

    c. Press T (to Terminate the monitor).

 2. Copy the up-to-date version of MSHELP.DLL from the distribution
    disk:

    a. Insert the Setup/Compiler 1 Disk into Drive A.

    b. Change the default Drive A.

    c. Run Setup with the /copy option by typing the following:

          setup /copy

    d. Press ENTER

    e. Press ENTER again (unless the setup files are in a drive other
       than A).

    f. At the prompt asking for the name of the file to copy, type
       MSHELP.DLL and press ENTER.

    g. At the prompt asking for the name of the directory to which to
       copy this file, type the directory in which the old MSHELP.DLL
       is located (most likely C:\OS2\DLL).

    h. Setup should then ask for the Programmer's WorkBench/Utilities
       for OS/2 Disk to be inserted into the setup drive.

    i. When Setup is finished copying the file, press ENTER at the
       next prompt.

 The PWB should now start up correctly.


 9. U1355 Bad Command or File Name

 Product Version(s): 1.00   | 1.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | docerr filename
 Last Modified: 27-SEP-1990    ArticleIdent: Q61607

 The following undocumented error may occur when attempting to run an
 executable file such as CL.EXE, LINK.EXE, NMAKE.EXE, etc., from inside
 the Programmer's WorkBench (PWB).

    U1355 Bad Command or File Name

 The error occurs because the directory containing the .EXE file is not
 specified in the search path or an incorrect LINK.EXE is being
 executed.

 This problem can be corrected by adding the missing directory name(s)
 to the path in the AUTOEXEC.BAT or STARTUP.CMD and rebooting, or
 executing NEW-VARS.BAT or NEW-VARS.CMD. If an incorrect linker is the
 problem, the search path can be rearranged to find the new version of
 the linker first, or the old linkers can be deleted or renamed.
 Finally, it may be necessary to delete the CURRENT.STS and PROG.STS
 files before the PWB will work correctly. This error is not documented
 in the PWB online help.


 10. Saving Compiler Results File in the PWB

 Product Version(s): 1.00   | 1.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified: 25-MAY-1990    ArticleIdent: Q61636

 The Programmer's WorkBench (PWB) deletes the compiler results file
 upon exiting the PWB. In DOS or OS/2, the file can be saved if the
 compiler results window is made current and the File.Save As menu
 option is selected.

 The compiler results file will appear similar to the following:

    +++ PWB  [E:\] Rebuild
            NMAKE  /z /a /f E:\pwb.mak
         cl /c /W4 /Fm /Ot /FoGLOBL.obj GLOBL.C
    Microsoft (R) C Optimizing Compiler Version 6.00
    Copyright (c) Microsoft Corp 1984-1990. All rights reserved.

    GLOBL.C
         echo @GLOBL.lrf > NUL
         link @GLOBL.lrf

    Microsoft (R) Segmented-Executable Linker  Version 5.10
    Copyright (C) Microsoft Corp 1984-1990.  All rights
    reserved.

    Object Modules [.OBJ]: GLOBL.obj,GLOBL.exe,NUL, /NOD:SLIBCE
    SLIBCEP , /NOI /BATCH /EXE /FAR /PACKC;


 11. Programmer's WorkBench Edit Switch Is Unimplemented

 Product Version(s): 1.00   | 1.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | docerr
 Last Modified: 14-MAY-1990    ArticleIdent: Q61642

 The edit switch for the Programmer's WorkBench (PWB), documented on
 Page 79 of the version 6.00 "Microsoft C Reference" manual, is
 unimplemented in PWB version 1.00. The switch is designed to set the
 active file as read-only so that it cannot be edited.

 If you add an option in your TOOLS.INI file under the PWB tag to read
 either

    Edit:yes
    Edit:no

 PWB will return an error message saying "Edit is not an editor
 switch."

 As a workaround, invoke PWB with the /r option to open up the current
 file as read-only.


 12. Certain Key Sequences Cause R6003 or SYS1943 in PWB 1.00

 Product Version(s): 1.00   | 1.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | buglist1.00 fixlist1.10
 Last Modified:  4-FEB-1991    ArticleIdent: Q61660

 In the Programmer's Workbench (PWB) version 1.00, it has been observed
 that certain unusual editing sequences can cause the following errors:

 In DOS:

    Run-time error R6003 - integer divide by 0

 In OS/2:

    SYS1943 protection violation, trap number 13

 The following sequences reproduce the errors:

    Procedure                             Keystrokes
    ---------                             ----------

 1. Bring up several files.               ALT+F O x3
    Select the Options menu.              ALT+O
    Select Linker options.                L
    Select Set Debug Options.             ALT+G
    Pull up help on the options.          F1
    Arg-refresh through several files.    ALT+A SHIFT+F7 x3
    Escape back to the Editor screen.     ESC x3

 2. Select the Options menu.              ALT+O
    Select Editor Settings.               S (or K)
    Go down thirteen lines.               DOWN ARROW key x13
    Backspace.                            BACKSPACE
    Undo.                                 ALT+BACKSPACE

 Note: Step 2 reproduces only the R6003 error in DOS, not the SYS1943
 error.


 13. PWB 1.00 Requires Decimal Value for Stack Size in LINK Options

 Product Version(s): 1.00    | 1.00
 Operating System:   MS-DOS  | OS/2
 Flags: ENDUSER | buglist1.00 fixlist1.10
 Last Modified:  5-FEB-1991    ArticleIdent: Q61871

 In the Programmer's WorkBench (PWB) version 1.00, there is a problem
 with changing a program's stack size in some situations. When
 specifying the stack size in the Link Options dialog box (from the
 Options menu), you must enter the value in the form of a decimal
 integer. Although the Help menu tells you this field accepts positive
 integers in octal and hexadecimal form, PWB 1.00 will not accept them.

 When an octal or hexadecimal value is entered in the stack-size field,
 any digits specified as A-F are discarded and replaced by 0 (zero). If
 digits precede a letter, the digits are retained and the letters are
 discarded.

 Microsoft has confirmed this to be a problem in PWB version 1.00. This
 problem was corrected in PWB version 1.10.


 14. SYS0002 Produced If MSHELP.DLL Not Installed

 Product Version(s): 1.00
 Operating System:   OS/2
 Flags: ENDUSER | pwbhelp
 Last Modified: 23-JAN-1991    ArticleIdent: Q61955

 Under OS/2, if MSHELP.DLL is not installed correctly or is not on the
 LIBPATH, the following error may appear in a window when starting the
 Programmer's WorkBench (PWB):

                     Cannot Autoload Extension
                     e:\c600\binp\pwbhelp.pxt
 MSHELP:  SYS0002:  The system cannot find the file specified

                         < OK >   < Help >

 Make sure that the latest version of MSHELP.DLL (the one that was
 included with the Microsoft C Compiler version 6.00) is installed in a
 directory contained in your LIBPATH.

 If this file was not copied off the disks during setup, you can
 execute the following command with your Setup disk in Drive A:

    a:setup /copy

 Specify the file MSHELP.DLL at the prompt, then specify the
 destination directory.

 The default for SETUP.EXE is to put OS/2 DLLs in the C:\OS2\DLL
 directory. If you choose to install the DLLs in some other directory,
 you must edit the LIBPATH in your CONFIG.SYS file and restart the
 system.


 15. Enabling of Source Browser Menu Related to .BSC and .MAK Files

 Product Version(s): 1.00   | 1.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified: 29-MAY-1990    ArticleIdent: Q61968

 The Source Browser feature of the Programmer's WorkBench (PWB) is
 enabled or disabled depending upon the existence of a database file
 (.BSC file) AND a program list (.MAK file). The existence of a .BSC
 database file alone does not guarantee that the Browse menu will be
 enabled for all modules in a project, even if the .BSC file was built
 from .SBR files for every module. The setting of a program list is
 also required.

 Thus, if a .BSC file is built outside of the PWB with PWBRMAKE, then
 upon entering the PWB, the Browser will be enabled for only one module
 at most (see below). The easiest method to enable the Browse menu for
 ALL modules is to select "Set program list" on the Make menu, then
 type in the base name of the .BSC file (with the .MAK or no extension)
 when it prompts you for the filename. If the .MAK file you enter does
 not exist, then the dialog box appears for adding files to the program
 list, whereas you can just select "Save List" without actually adding
 any files. At this point, the Browser menu will be enabled for all
 files you bring up into the PWB editor.

 The existence of a Source Browser database file means that the Browse
 menu will be enabled for a source file with a matching base name of
 the .BSC file.

 For example, assume a project consists of several modules, with the
 main source module called PROJECT.C. In addition, assume a Browser
 database file called PROJECT.BSC is built from the .SBR Browser
 information files produced by the compiler for every module in this
 project. If the file PROJECT.C is brought up in the PWB, the Browse
 menu will be enabled because the base name (PROJECT) is the same as
 the base name of the database file PROJECT.BSC.

 On the other hand, if any of the other source files in the project are
 opened in the PWB, the Browse menu will be disabled because the base
 names do not match the base name of the database file. Also, if
 PROJECT.C is made the current file (which enables the Browse menu) and
 an option is selected on the browse Menu, such as "Goto Reference"
 (which causes a jump to a different module), the Browse menu will
 become disabled. The only way to re-enable the Browse menu in this
 case is to make PROJECT.C the current file again.

 The way to enable the Browse menu for all modules is to set a program
 list to a file with the .MAK extension and the same base name as the
 .BSC file. Thus, in the example above, setting the program list to
 PROJECT.MAK will enable the Browse menu for all modules. In fact, this
 connection between the .BSC file and the .MAK file enables the Browse
 menu for the modules in the current project, and for ANY file opened
 under the PWB.

 The result is that if you bring up a file in the editor that is
 completely unrelated to the current project (and may not even have a
 related .BSC file), you can still use the Browse menu options.
 However, in this situation, the information available from the Browser
 still only pertains to the original project.

 In summary, the .MAK file and .BSC file relationship is based solely
 on the file existence, NOT the file contents. The program list does
 NOT need to contain the names of the modules in the current project
 (or even be an actual makefile) for the Browser to function.


 16. Modifying TOOLS.INI May Have No Effect on PWB Environment

 Product Version(s): 1.00   | 1.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified: 17-JUL-1990    ArticleIdent: Q62170

 Changing settings in the TOOLS.INI file to modify the behavior of the
 Programmer's WorkBench (PWB) may not work under certain circumstances.
 For instance, if you decide to change the PWB to 50-line mode by
 setting "height:50" in the TOOLS.INI file, it will not work if the PWB
 was previously used in the 25- or 43-line mode.

 This is because some environment information is also recorded in the
 CURRENT.STS file, which is read in after the TOOLS.INI file --
 overriding the TOOLS.INI settings.

 The following are three workarounds for this problem:

 1. Use the /DS switch when invoking the PWB. This will ignore the
    CURRENT.STS file. However, this option also causes the current file
    history (of files being edited) to be ignored.

 2. Delete the CURRENT.STS file. This also causes the current list of
    programs being edited to be ignored.

 3. The better option is to select Editor Settings from the Options
    menu. When the list of editor switch settings appears, it can be
    changed and saved to the TOOLS.INI file by pressing SHIFT+F2. This
    will save the settings and cause the selection to take effect.


 17. Reversing Mouse Buttons in the PWB Cannot Be Done

 Product Version(s): 1.00   | 1.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified: 25-JUL-1990    ArticleIdent: Q62330

 Currently under the Programmer's WorkBench (PWB) released with version
 6.00 of the Microsoft C Optimizing Compiler, it is not possible to
 reverse the functionality of the mouse buttons.

 It is possible to change the functionality of the mouse buttons under
 OS/2 and DOS, but this will be overridden by the PWB environment.


 18. Attempting to Expand a Help Dialog Box Hangs DOS

 Product Version(s): 1.00   | 1.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | buglist1.00
 Last Modified: 25-JUL-1990    ArticleIdent: Q62331

 When one of the pull-down menus in the Programmer's WorkBench (PWB)
 version 1.00 is selected (File, Edit, View, etc.) and then F1 is
 chosen for help on that menu, a small help screen appears. If CTRL+F10
 is chosen in an attempt to expand the window to full screen, the
 machine will hang under DOS. If the machine doesn't hang, it may
 require another invocation of CTRL+F10 to cause the problem.

 Under OS/2, the machine may not hang, but the PWB's functionality will
 be disrupted and attempts to free oneself may cause a GP fault. It may
 be possible to exit the PWB, but at the very least, the CURRENT.STS
 file will be corrupted so that future entrances to PWB will result in
 very odd window configurations.

 Microsoft has confirmed this to be a problem with the PWB version
 1.00. We are researching this problem and will post new information
 here as it becomes available.


 19. PWB Doesn't Update Mark Location If Mark Moves Up or Left

 Product Version(s): 1.00 | 1.00
 Operating System:   OS/2 | 1.00
 Flags: ENDUSER | buglist1.00
 Last Modified: 13-JUN-1990    ArticleIdent: Q62388

 If you set a mark in a file, and that location then moves upward or
 toward the left in the file, PWB does not reset the mark location;
 however, it does correctly update marks that move downward or to the
 right in the file.

 Consider the following file:

 /* Test.dat */
 test1

 test2

 test3

 Place the cursor on the "2" in test2. Choose the Search.Define Mark
 menu option. Name the mark "mark1" and press ENTER. Now, move the
 cursor to another location in the file. Choose the Search.Go To Mark
 option from the menus. Go to "mark1". Note that the cursor is back on
 the "2" in test2.

 Next, add another blank line between test1 and test2. Again, move your
 cursor and go to mark1. Note that the cursor is back on the "2" in
 test2.

 Now, delete both the lines between test1 and test2. Select the
 Search.Go To Mark option from the menus. Note that the cursor is on
 the same location as it was before you deleted these lines. The same
 behavior will happen if you delete any of the characters before the
 "2" in the test2 line.

 Microsoft has confirmed this to be a problem in the Programmer's
 WorkBench (PWB) version 1.00. We are researching this problem and will
 post new information here as it becomes available.


 20. PWB 1.00 "Set Dependencies" Fails with Spaces in #include Line

 Product Version(s): 1.00   | 1.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | buglist1.00 fixlist1.10 s_c
 Last Modified:  5-FEB-1991    ArticleIdent: Q62578

 The Programmer's WorkBench (PWB) version 1.00 (shipped with C version
 6.00) includes a "Set Dependencies" option in the "Set Program List"
 window. This option automatically sets up build dependencies for all
 include files used in the current project. This option will fail with
 a message that the include file does not exist if there are embedded
 spaces between the left angle bracket (<) and the include-file name in
 an include directive line.

 The Set Dependencies option will work correctly if the space(s) are
 removed or if a new build option is added to the TOOLS.INI file.

 Although embedded spaces are legal in C programming syntax, the
 Programmer's WorkBench fails to parse the include line correctly if
 spaces exist before the filename. The following line of code shows the
 situation where the "Set Dependencies" error will occur:

    #include < stdio.h >

 The space before the "s" in stdio.h prevents PWB from finding the
 STDIO.H include file. (The trailing space after stdio.h does not
 affect the behavior of "Set Dependencies".)

 The full text of the error message window for the line above is as
 follows:

         stdio.h does not exist
    Cannot build its dependency tree.
    Abort dependency lists generation?
         <Yes>    <No>    <Help>

 Selecting <Help> displays a help screen that describes the problem as
 being either a mistyped filename or a nonexistent file, but the actual
 file DOES exist. Removing the embedded space will correct the problem.

 You can also add two new "build" lines to the TOOLS.INI file to make
 the PWB recognize include directives that contain spaces. These lines
 should be included under the section with the [PWB] tag, and should
 have the following syntax:

    build: include .c                                              \
        "^[ \t]*#[ \t]*include[ \t]*\"[ \t]*\\([^\"]+[ \t]*\\)\""  \
        case
    build: include .c                                              \
       "^[ \t]*#[ \t]*include[ \t]*<[ \t]*\\([^>]+\\)[ \t]*>"      \
        case system

 (Note: These build switch statements are broken down into multiple
 lines with the line continuation character (\) because of space
 limitations; you may enter each of them into the TOOLS.INI file on a
 single line, rather than multiple lines.)

 There is one drawback to this workaround; you will still get the error
 message shown above because the "old" build switch is applied before
 the new one. To have the new build switch take effect, you need to
 select "No" when prompted to abort the dependency list generation.
 Once you have selected "No" for each file with spaces in the include
 directive, the dependencies will then be generated correctly.

 Microsoft has confirmed this to be a problem in the Programmer's
 WorkBench version 1.00. This problem was corrected in the Programmer's
 WorkBench version 1.10.


 21. PWB 1.10 Dialog Boxes May Blink After Dialog Help Is Obtained

 Product Version(s): 1.10
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist1.10 flicker
 Last Modified: 19-FEB-1991    ArticleIdent: Q69347

 When working with the Programmer's WorkBench (PWB) version 1.10 under
 DOS, there are several instances where a dialog box may start flashing
 incorrectly. This situation occurs when you obtain help on a PWB
 informational pop-up dialog box and then return from the Help dialog
 screen. At this point you may find that the original dialog box is
 rapidly blinking.

 This problem may occur when trying to get help on a topic for which
 there is no help, trying to use an unassigned key, or when PWB informs
 you that you changed a file but didn't save it before you tried to
 exit. In each of these cases, PWB gives you a pop-up dialog box
 informing you of the situation. If you get help on this informational
 dialog box and then press ESC or click Cancel, the original dialog box
 will start blinking.

 This is not normal behavior, however, PWB is still fully functional
 and you may proceed by selecting an appropriate choice from the
 flashing dialog box.

 Microsoft has confirmed this to be a problem in the Programmer's
 WorkBench version 1.10. We are researching this problem and will post
 new information here as it becomes available.


 22. R6000 Stack Overflow After Deleting Current Makefile

 Product Version(s): 1.00   | 1.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified: 25-JUL-1990    ArticleIdent: Q62668

 If you are viewing your makefile in a window in PWB 1.00, then delete
 the makefile from a shell; attempting to make the window containing
 the makefile active will cause a run-time error R6000, stack overflow.

 To duplicate this problem, bring up a sample program and set the
 program list to that file's makefile. Next, open up another window
 and open the makefile in that window. Now, either from the Run.Run
 <DOS-OS/2> Command menu or the File.<DOS-OS/2> Shell, delete that
 makefile.

 After returning back to the PWB, make the window containing the
 makefile the active program list either by pressing the F6 key to
 toggle windows or by clicking the left mouse button in that window.

 You will be faced with a popup message saying "File has been deleted
 from disk. Delete from memory?" Answering "yes" brings up the popup
 six to eight more times. Then, PWB will abort to the system prompt
 with an R6000 (stack overflow) error message and another message, "File
 has been deleted from disk."

 Microsoft has confirmed this to be a problem in PWB version 1.00. We
 are researching this problem and will post new information here as it
 becomes available.


 23. PWB 1.00 Extensions Only Return True Under DOS

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist1.00
 Last Modified: 15-AUG-1990    ArticleIdent: Q63052

 Extensions written for use by the Programmer's WorkBench (PWB) version
 1.00 under the DOS operating system are recognized as returning true
 regardless of their actual return values.

 The use of return values as a way of providing conditional jumps
 inside PWB macros is a common practice that is affected by the above
 limitation for PWB extensions. The following sample extension and
 macro demonstrate the above problem. Once installed, both the foo()
 and foo2() functions will be seen as returning true to PWB.

 Sample Code
 -----------

 // foo.c

 #include <string.h>
 #include <stdlib.h>
 #include <ext.h>

 PWBFUNC foo( unsigned argData, ARG far *pArg, flagType fMeta );
 PWBFUNC foo2( unsigned argData, ARG far *pArg, flagType fMeta);

 // Switches.
 struct swiDesc swiTable[] =
 {
    { NULL, NULL, 0 }
 };

 // Commands.
 struct cmdDesc cmdTable[] =
 {
    { "foo", foo, 0, NOARG },
    { "foo2",foo2,0, NOARG },
    { NULL, NULL, 0, 0 }
 };

 void EXTERNAL WhenLoaded()
 {
     SetKey( "foo",         "alt+f" );
     SetKey( "foo2",       "ctrl+f" );
     return;
 }

 PWBFUNC foo( unsigned argData, ARG far *pArg, flagType fMeta )
 {
  return(FALSE);  /* FALSE is defined as 0 in ext.h */
 }

 PWBFUNC foo2( unsigned argData, ARG far *pArg, flagType fMeta)
 {
  return(TRUE);   /* TRUE is defined as 1 in ext.h  */
 }

 // End of foo.c

 ; macros in tools.ini to test foo and foo2

 load foo

 test:=foo ->loc1 arg "true" message => :>loc1 arg "false" message
 test2:=foo2 ->loc2 arg "true" message => :>loc2 arg "false" message

 test:alt+t
 test2:ctrl+2

 Microsoft has confirmed this to be a problem with PWB version 1.00. We
 are researching this problem and will post new information here as it
 becomes available.


 24. PWB Text Highlight with Mouse Acts Strange After Search

 Product Version(s): 1.00   | 1.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified: 15-AUG-1990    ArticleIdent: Q63059

 The click-and-drag method of selecting text with the mouse in the
 Programmer's Workbench (PWB) sometimes works incorrectly when used
 after a search function.

 To reproduce this problem, do the following:

 1. Select a word in the text using the mouse (double-click on a single
    word).

 2. Execute the search function (select the Search menu, choose Find,
    then OK).

 3. Now try to highlight the text a few lines below the word you used
    to search on (using the click-and-drag method).

 The text will be highlighted starting at the original word that was
 searched for, rather than at the starting mouse position.

 To work around this problem, click the left button anywhere in the
 text window, then perform the text highlight.

 Microsoft has confirmed this to be a problem with the Programmer's
 Workbench version 1.00. We are researching this problem and will post
 new information here as it becomes available.


 25. PWB Does Not Return from DOS Shell with ";" in TMP

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 25-JUL-1990    ArticleIdent: Q62702

 If there is a semicolon ";" in your TMP environment variable, you may
 not be able to return to the Programmer's Workbench by typing "exit"
 after selecting "DOS Shell" from the File menu in PWB.

 Since the TMP environment variable is used to specify a single
 directory rather than a path, the semicolon character should not be
 used.

 To re-create this situation, type the following at the command line:

    set TMP=C:\TMP;

 Then select DOS Shell from within PWB. Typing "exit" on the DOS
 command line will not bring you back into PWB.

 To correct the problem, remove the semicolon from the end of the TMP
 environment variable.


 26. PWB BACKUP.BAK Does Not Create Backup of Source File Correctly

 Product Version(s): 1.00   | 1.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER| buglist1.00
 Last Modified: 24-JUL-1990    ArticleIdent: Q63234

 Version 1.00 of the Programmer's Workbench does not create a backup of
 your source file correctly if the PROJECT.MAK has the same base name
 as the SOURCE.C file. When you build or rebuild the project, the file
 saved as your backup is a copy of the CURRENT.STS file.

 A workaround to this problem is to name your PROJECT.MAK with a
 different base name than your SOURCE.C file. This will still save a
 copy of your CURRENT.STS file with the base name of the PROJECT.MAK.
 However, it will correctly save a backup of the SOURCE.C as
 SOURCE.BAK.

 Microsoft has confirmed this to be a problem in version 1.00 of the
 Programmer's Workbench and will post new information here as it
 becomes available.



 27. PWB menukey Switch Resets to ALT When Shelling Out to DOS

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist1.00
 Last Modified: 10-JUL-1990    ArticleIdent: Q63267

 If the "menukey" switch in the DOS version of the Programmer's
 Workbench (PWB) version 1.00 is set to anything other than ALT (which
 is the default), it will be redefined to the ALT key after shelling
 out to DOS. This means the menukey switch will lose its assignment
 anytime you choose Compile, Run Program, Debug Program, or DOS Shell.

 The menukey switch determines which keystroke activates the PWB main
 menu bar. The ALT key is normally used for this, but menukey can be
 redefined to any keystroke. For example, menukey is automatically
 defined to F9 if you select Brief Editor emulation when installing the
 Programmer's WorkBench.

 Whenever you invoke any function (such as Build) that goes out to DOS
 for execution and then returns, the menukey switch is reset to ALT, so
 that both ALT AND the user-defined keystroke invoke the menu.

 To work around this problem, you can use the Restart command to invoke
 a macro that redefines the menukey to the desired value each time you
 return from a DOS SHELL command, which will then keep ALT from
 activating the menu. For example, to make it so that F9 is always
 reset as the only menukey, put the following line in the PWB tagged
 section of the TOOLS.INI file:

    restart:= arg "menukey:F9" assign

 Since the Restart command, if it exists in TOOLS.INI, is invoked
 automatically when returning from a SHELL command, this guarantees
 that the key assignment will always remain consistent.

 Microsoft has confirmed that the automatic reactivation of ALT as the
 menukey is a problem with the Programmer's WorkBench version 1.00. We
 are researching this problem and will post new information here as it
 becomes available.


 28. PWB: Print Does Not Put CR/LF at EOL If Text Selected

 Product Version(s): 1.00   | 1.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | buglist1.00
 Last Modified: 25-JUL-1990    ArticleIdent: Q63318

 Using the Programmer's Workbench version 1.00, when a region of text
 is selected and the Print function is invoked, the resulting output
 contains linefeed characters (0x0A) at the end of each line, rather
 than a carriage return/linefeed (<CR><LF>) combination (0x0D and
 0x0A).

 Some printer drivers do not recognize this as a valid end-of-line
 (EOL) character and do not print correctly.

 To reproduce this problem, open a file that contains the <CR><LF>
 combination at the end of each line. Highlight a region of text in the
 file and from the File menu choose Print. Tab to the second field and
 type in the following:

    copy %s test.txt

 This will copy the region of selected to the file TEST.TXT. Using a
 standard hex file viewer, you can see that the end of a line is
 denoted by a single 0A. If you look at the original file using the hex
 viewer, it will contain 0A 0D at the end of each line.

 The Programmer's Workbench will recognize this type of file (with a
 single 0A at each end of line) and display it correctly if you try to
 open it within the Workbench, but many printer drivers do not
 understand this type of file.
 The workaround for this problem is to write a program that translates
 each 0x0A found in the output file to the bytes 0x0D and 0x0A, or use
 a printer driver that understands this type of file. In fact, most
 printers have an escape sequence or dip switch to make it recognize
 this type of file.

 Microsoft has confirmed this to be a problem with the Programmer's
 Workbench version 1.00. We are researching this problem and will
 post new information here as it becomes available.


 29. Unknown Function psrch with Brief Emulation in PWB

 Product Version(s): 1.00   | 1.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified: 25-JUL-1990    ArticleIdent: Q63319

 When using the Brief emulation feature of the Programmer's WorkBench
 version 1.00, reinitialization of the TOOLS.INI file will cause a
 number of unknown functions to appear when you try to use them. In
 short, most of the unknown functions that may be reported are related
 to search features such as the psearch switch. The error message
 associated with this search feature is commonly "Unknown function
 psrch."

 This error occurs only after you use the Initialize function.

 The Initialize function discards current macro definitions and rereads
 the appropriate section of TOOLS.INI. This is not exactly the same as
 restarting PWB; the Autostart macro is not executed after Initialize.
 The BRIEF emulation depends on the Autostart macro to define the
 search functions.

 To recover the definition of the missing macros, execute the toggle_re
 BRIEF emulation macro (CTRL+F6). To avoid having to remember to
 execute this macro, you can add this to the main section of TOOLS.INI:

    reinit:=Initialize Autostart
    reinit:Shift+F8

 Or you can define the macros as follows:

    psrch:=arg arg "String to Search for" prompt ->can
                                            psearch => :>can cancel
    msrch:=arg arg "String to Search for" prompt ->can
                                            msearch => :>can cancel
    qrepl:=arg arg qreplace
    srchname:="REoff"


 30. Problems Viewing README.DOC Inside PWB Online Help and QH

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER  |
 Last Modified: 15-AUG-1990    ArticleIdent: Q63661

 Problems can occur when attempting to access the README.DOC from
 within the DOS versions of Programmer's WorkBench (PWB) or QH via the
 online help.

 When attempting to view the README.DOC file using the online help
 inside the DOS version of PWB, the messages "Error displaying help"
 and then "Cannot process cross reference" may be displayed in
 successive dialog boxes.

 When attempting to view the README.DOC file from within QH, the
 message "The database README.DOC is not open, or the topic is not
 found" may be displayed.

 Again, these problems are found only in the DOS version of PWB and QH.
 Access of the README.DOC in this manner does not produce errors under
 the OS/2 versions of PWB or QH.

 The following are two possible workarounds for the problem in PWB:

 1. The README.DOC can be loaded into the help system by typing the
    following

       arg "$PATH:readme.doc!" arg pwbhelp

    with default keys:

       Alt+A $PATH:readme.doc! F1

    Note that this method may fail if there is another file named
    README.DOC in the path before the C 6.00 README.DOC. If this is the
    case, the other README.DOC will be loaded instead of the C 6.00
    README.DOC. This method can also fail if there is not enough memory
    to load the file into the help system.

 2. If the previous method fails, the C 6.00 README.DOC can be loaded
    into PWB as a normal text file via the File.Open menu option. The
    README.DOC can be found in the C 6.00 bound executable directory
    (for example, C:\C600\BINB).

 The following are three possible workarounds for the problem in QH:

 1. Inside QH, select View.Search, type "$PATH:readme.doc!" and press
    ENTER. Again, this will bring up the first README.DOC on the path.

 2. You can also select File.Open and load the the file by giving the
    full path and filename of the C 6.00 README.DOC. QH allows you to
    open any text file under 64K in size.

 3. To enable direct access of the README.DOC from within QH via the
    README.DOC button, it is necessary to point the QH environment
    variable to the directory where the README.DOC is located. For
    example:

       set qh=c:\c600\binb\readme.doc

    The QH environment variable is not documented in the C 6.00 printed
    or online documentation.

 Microsoft is researching this problem and will post new information
 here as it becomes available.


 31. CTRL+NUM/ May be Read as CTRL+/ in DOS with NUM LOCK On

 Product Version(s): 1.00 1.10 | 1.00 1.10
 Operating System:   MS-DOS    | OS/2
 Flags: ENDUSER | buglist1.10
 Last Modified: 15-NOV-1990    ArticleIdent: Q66740

 In versions 1.00 and 1.10 of Programmer's WorkBench (PWB), the
 CTRL+NUM/ (CTRL+/ on the numeric keypad) and ALT+NUM/ (ALT+/ on the
 numeric keypad) combinations may be interpreted as CTRL+/ and ALT+/
 (on the main keyboard). This problem happens only in DOS or the OS/2
 DOS 3.x box, and only on certain computers. This behavior will cause
 any macro or function assigned to CTRL+NUM/ or ALT+NUM/ to not execute
 when NUM LOCK is on.

 To reproduce this problem, assign a function or macro to CTRL+NUM/.
 Then execute the TELL function (CTRL+T by default) and press CTRL+NUM/.
 The TELL function prompts for a keystroke, then displays the name of
 the keystroke and the function assigned to it. With NUM LOCK on, TELL
 will return the following:

    unassigned:Ctrl+/.

 With NUM LOCK off, TELL will return the following:

    <function name>:Ctrl+num/.

 This behavior is identical for the ALT+NUM/ key name, but works
 properly for all other key names on the numeric keypad.

 If NUM LOCK is off, or if the protected-mode version of PWB is run,
 this behavior does not occur.

 This behavior has been observed on the following machines:

    Northgate 386-33
    PS/2 Model 70
    PS/2 Model 80-311

 Microsoft has confirmed this to be a problem in PWB version 1.00 and
 1.10. We are researching this problem and will post new information
 here as it becomes available.


 32. PWB Command-Line Option /DP Is Documented But Not Implemented

 Product Version(s): 1.00   | 1.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | docerr
 Last Modified: 27-JUL-1990    ArticleIdent: Q63951

 The /DP switch for the Programmer's WorkBench (PWB), documented on
 Page 49 of the version 6.00 "Microsoft C Reference," is not
 implemented in version 1.00 of the PWB. This switch is designed to
 ignore the most recent program list upon starting the PWB.

 The /DP switch is mentioned only in the "Microsoft C Reference" and
 not in the online help.

 Upon invocation, the Programmer's WorkBench version 1.00 does not
 automatically set the program list to the last program list used.
 Therefore, the /DP command-line switch was not implemented because it
 would have no purpose.

 With the PWB version 1.00, there is no way to have the last program
 list set automatically at startup.


 33. With the "deflang" Switch PWB Prompts for Setting Program List

 Product Version(s): 1.00   | 1.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | docerr
 Last Modified:  3-AUG-1990    ArticleIdent: Q64353

 As documented on Page 79 of the "Microsoft C Reference" shipped with C
 version 6.00 and in the online help, the "deflang" switch in the
 Programmer's WorkBench (PWB) sets the default filename extension for
 list boxes in PWB dialog boxes. Another (undocumented) feature of this
 switch is to enable you to be prompted to "Set Program List?" when
 loading a source file with a .MAK file associated with it in the
 current directory.

 By default, "deflang" is not set. You can set the deflang switch in
 the [PWB] tagged section of the TOOLS.INI file, for example:

    deflang:C

 This changes the default filename extension in the PWB's dialog boxes
 (such as Open in the File menu) from "*.*" to "*.c", so that only
 files with the .c extension show up by default. Other languages can be
 specified as well, as shown below:

    Switch Setting     Extension
    --------------     ---------

    no value            .*
    C                   .c
    Asm                 .asm
    BASIC               .bas
    FORTRAN             .for
    Pascal              .pas
    COBOL               .cbl
    LISP                .lsp

 Note that the online documentation specifies "Assembler" as the switch
 to use for .ASM files, but this is incorrect. "Asm" is the correct
 switch to use to make Assembler the default language.

 The deflang switch also enables you to be prompted as to whether or
 not the program list should be set automatically. If you load a file
 that has the extension specified by the "deflang" switch and you also
 have a .MAK file with the same base filename in the same directory,
 the PWB will prompt you about loading the program list.

 For example, assume that deflang is set to C and FOO.MAK and FOO.C are
 in the same directory. If you type PWB FOO.C at the command-prompt,
 the PWB will pause when loading and prompt with "Set Program List?
 FOO.MAK". At this point you can specify <yes> or <no>.

 When already in the PWB, if you select Open from the File menu, and
 select FOO.C as the file to open, the PWB will also prompt you at this
 point regarding whether or not you want FOO.MAK loaded as the program
 list, but only if NO program list is currently set.


 34. Can't Resize a Window with a Macro in PWB

 Product Version(s): 1.00   | 1.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified: 30-AUG-1990    ArticleIdent: Q64433

 A window cannot be resized using the "resize" function in a macro.
 After Programmer's WorkBench (PWB) performs the resize function, it
 waits for the you to respond with the UP ARROW or DOWN ARROW key.
 Functions that are placed in the macro after the resize function are
 ignored. If "record on" is selected and you try to record the resizing
 of a window, the macro will stop recording until the ENTER key on the
 numeric keypad is pressed.

 The following is an example:

    resizeit:= cancel arg arg nextmsg window resize up up up NumEnter

 The above example stops at the resize function and waits for you to
 resize the window. The remaining functions are ignored.

 To make a window a specified size, move the cursor to a location on
 the screen and then open the window with the "window" function.

 The following is an example of a macro that opens the "<compile>"
 window with a specified size:

 compile_size:= up up up up up up up up up up
 resize_it:=cancel meta down compile_size arg window window arg \
            "<compile>" setfile window
 resize_it:ALT+U

 Note: The size of the compile window can be adjusted by changing the
 number of ups on the compile_size line.


 35. PWB Hangs When Run with Some Communication Programs Under OS/2

 Product Version(s): 1.00
 Operating System:   OS/2
 Flags: ENDUSER |
 Last Modified: 30-AUG-1990    ArticleIdent: Q64435

 When running Programmer's WorkBench (PWB) under OS/2 while
 simultaneously running communication programs, PWB will appear to
 hang. To correct the problem, terminate any communication programs and
 PWB will resume as normal.


 36. "Cannot Open File current.$" May Mean Incorrect INIT Variable

 Product Version(s): 1.00   | 1.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified: 17-DEC-1990    ArticleIdent: Q64566

 When using the Programmer's Workbench (PWB), the following message may
 appear as a pop-up dialog box when selecting Compile or DOS Shell (or
 OS/2 Shell for OS/2):

    +----- Cannot open file! -----+
    |   D:\TEST\SRC\X\current.$   |
    |  No such file or directory  |
    |-----------------------------|
    |      < OK >   < Help >      |
    +-----------------------------+

 One cause for this error is an incorrect setting of the INIT
 environment variable. To remedy the situation, exit PWB and make sure
 that the INIT environment variable is set to a valid directory name
 (for example, a directory that exists).

 To reproduce this message, set your INIT environment variable to an
 invalid directory, for instance (if a directory named X does not exist
 on your drive):

    SET INIT=X

 Then start PWB and try to compile a program. The message will appear
 in the middle of the screen.

 One possible reason why your INIT environment variable may be set
 incorrectly, even if your AUTOEXEC.BAT sets it correctly, is that you
 might have run out of environment space in the setting of the
 variable. You can refer to the "MS-DOS Encyclopedia," Article 2, for
 more information about increasing your environment space.


 37. How to Use the PWB with the Windows 3.00 SDK

 Product Version(s): 1.00   | 1.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified: 15-AUG-1990    ArticleIdent: Q64788

 Detailed step-by-step instructions on how to set up the Programmer's
 WorkBench (PWB) for use with the Windows version 3.00 Software
 Development Kit (SDK) can be found in a file provided with the SDK
 called PWBINFO.WRI.

 The file explains how to set PWB switches so that Windows applications
 can be built from within PWB. The file also explains how to access the
 SDK's online help.

 This file can be viewed and printed with the WRITE program, which is
 packaged with the Windows 3.00 package.


 38. Tips for Using the Microsoft Advisor Online Help

 Product Version(s): 1.00 1.10 | 1.00 1.10
 Operating System:   MS-DOS    | OS/2
 Flags: ENDUSER | s_quickc s_c s_qh
 Last Modified: 23-JAN-1991    ArticleIdent: Q64829

 The following are some tips for more effectively using the online
 documentation included with the Microsoft C Compiler version 6.00
 Programmer's Workbench (PWB) as well as the Microsoft Advisor
 command-line help system:

 1. Finding help on a topic for which the exact name is not known.

    If the exact spelling of a topic is not known, the help for that
    topic can't be accessed directly (for instance, by using the F1 key
    in PWB), but it can usually be found indirectly.

    By using the table of contents and selecting links that pertain to
    the subject in question, the topic can usually be found. To get to
    the table of contents from within QuickHelp, select the Categories
    menu, then "C 6.00".  From within PWB, choose the Help menu, then
    select Contents.

    If you know the general spelling of the topic, an alphabetical
    index is available by choosing Index from the main contents screen.

 2. "Paging" through the online documentation.

    The online documentation can be "paged through" like you would page
    through a manual.

    In PWB, CTRL+F1 takes you from one topic to the next sequential
    topic in the help file. In QuickHelp, Choose Next or Back from the
    View menu to move in either direction.

 3. Scanning a list of available topics (as in a printed index).

    There are alphabetical indices for every major component of the
    product. Just choose Index from the main contents screen and select
    the appropriate topic.

 4. Techniques for using the online help.

    For more information on how to use the help system, as well as on
    the general organization and structure of the help system, choose
    Using Help from the main contents screen.

    For additional help, see Chapter 4, "Using the On-Line Reference,"
    of the "Microsoft C Installing and Using the Professional
    Development System" manual that comes with C version 6.00.

 5. Printing out the online help files.

    By using the HELPMAKE utility, the help files can be decoded to
    readable text files, which can then be printed. For more
    information about the HELPMAKE utility, see Chapter 7 of the
    "Microsoft C Advanced Programming Techniques" manual that comes
    with C version 6.00.


 39. Predefined Identifiers in Microsoft C 6.00

 Product Version(s): 6.00   | 6.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | s_quickhelp s_c s_utils
 Last Modified: 24-OCT-1990    ArticleIdent: Q65472

 The following information is contained in the online help for the
 Microsoft C Compiler version 6.00.

 This information below can be accessed by using the following steps:

 1. Obtain help on the text "cl" using either the F1 key from the
    Programmer's WorkBench, or by using "qh cl" from the DOS or OS/2
    command lines.

 2. Select Preprocessor Options, then Predefined Identifiers.
 The compiler automatically defines identifiers useful in writing
 portable programs. You can use these identifiers to compile code
 sections conditionally. These identifiers are always defined unless
 otherwise stated.

    Identifier       Target Identified
    ----------       -----------------

    MSDOS            MS-DOS operating system
    M_I86            Member of the I86 processor family
    M_I86mM          Memory model type
                     <m> = T    Tiny
                           S    Small (default)
                           C    Compact model
                           M    Medium model
                           L    Large model
                           H    Huge model
    M_I8086          8088 or 8086 processor; default or with /G0
                        option
    M_I286           80286 processor; defined with /G1 or /G2 option
    _MSC_VER         Identifies the version of Microsoft C
    NO_EXT_KEYS      Disables Microsoft-specific language extensions
                        and extended keywords; defined only with /Za
                        option
    _CHAR_UNSIGNED   Changes default char type to unsigned; defined
                        only with /J option

 The _MSC_VER identifier has a value of 600 for the Microsoft C Compiler
 version 6.00. This identifier is not defined in Microsoft C versions
 5.10 and earlier.


 40. How to Add Other Language Compilers to PWB's Build Options

 Product Version(s): 1.00 1.10 | 1.00 1.10
 Operating System:   MS-DOS    | OS/2
 Flags: ENDUSER | s_pascal b_basiccom s_c h_masm h_fortran b_cobol
 Last Modified: 24-OCT-1990    ArticleIdent: Q65568

 The Programmer's WorkBench (PWB) is an environment capable of
 utilizing different compilers for mixed-language programming. When
 installed during BASIC version 7.10 setup, PWB version 1.10 shows
 build options for the BASIC language only. However, it is possible to
 include other language compilers to utilize the full features of the
 PWB utility.

 The following information applies to the Programmer's WorkBench
 version 1.10 utility supplied with Microsoft BASIC Professional
 Development System (PDS) version 7.10 for MS-DOS and MS OS/2.

 Note that the 1.00 version of PWB is shipped with Microsoft C
 Professional Development System (PDS) version 6.00. The steps below
 should also apply to PWB version 1.00.

 The Programmer's WorkBench (PWB.EXE) is an advanced development
 environment capable of integrating several language compilers,
 NMAKE.EXE, LINK.EXE, and the CodeView debugger. It offers the ability
 to accomplish tasks, such as program development under protected mode
 and mixed-language programming. This ability is not available in the
 QuickBASIC extended development environment (QBX.EXE).

 Two special files, PWBC.PX$ (for protected mode OS/2) and PWBC.MX$
 (for DOS mode), reside on the BASIC PDS 7.10 disks and support the
 option of using the C compiler in PWB. Since SETUP.EXE (in BASIC PDS
 7.10) does not copy PWBC.PX$ and PWBC.MX$ during installation, these
 files must be unpacked and transferred to your machine, for example to
 the \BINP subdirectory located in the \BC7 directory. (Note: The
 UNPACK.EXE utility is found on disk 1 of the BASIC PDS package.) After
 unpacking, the files will have the names PWBC.PXT and PWBC.MXT.

 Next, the following command lines must be added to the TOOLS.INI file
 to make the C compiler available to PWB:

    [pwb - .BAS .BI]
       LOAD: LogicalDrive:\[Path]\PWBC.PXT

 For further information about installing PWBC.PXT and PWBC.MXT, see
 Page 54 of the "Microsoft BASIC 7.1: Getting Started" manual.

 If you want to program in languages other than BASIC or C [such as
 Microsoft Macro Assembler (MASM), Microsoft Pascal, Microsoft FORTRAN,
 or Microsoft COBOL 3.00/3.00a], the following steps will insert the
 initial build options to include other languages to PWB's build
 options menu. In the example below, options to include the MASM.EXE
 assembler are specified. If some other language's compiler is desired,
 substitute appropriate changes for that compiler, where noted in the
 specified areas:

  1. In PWB, go to the Options menu and select Build Options.

  2. Choose Save Current Build Options.

  3. Enter a meaningful message, such as "Options to Include MASM" in
     the window's edit field (if some other language is desired, change
     MASM to the appropriate name). Select the OK button from the "Save
     Current Build Options" and "Build Options" windows.

  4. Open the "TOOLS.INI" file in the PWB utility and go down to the
     bottom of the file. Somewhere near the bottom should be the tag
     "[PWB-Build Options: Options to Include MASM]" (or the language
     that was specified).

  5. In this section, add the following NMAKE instructions:

        build: inference .asm.obj masm_asm_obj
        build: command masm_asm_obj "masm $<;"

     Note: For languages other than MASM, distinguish a variable name
     in the inference rule to be used in the commands line (such as
     masm_asm_obj has been used above) and then specify the appropriate
     compiler in the commands line within the quotation marks. The
     special filename macro specified in the quotation marks, "$<",
     applies the command to any object that has an out-of-date
     executable file.

  6. Press SHIFT+F8 to reinitialize the file and then close it.

  7. Go to the File menu and select New (it is a good idea to close any
     files that are currently open before this step).

  8. Go to the Options menu and select Build Options.

  9. Choose Initial Build Options.

 10. Select the "Options to Include MASM" option (it should be near the
     bottom of the list).

 After completing these instructions, the PWB utility will now be ready
 to compile assembler along with BASIC source code, provided that paths
 to the necessary compilers are furnished.


 41. PWB Err Msg: Out of Local Memory. Unable to Recover.

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 17-OCT-1990    ArticleIdent: Q65913

 When setting a program list inside of the Programmer's WorkBench
 (PWB), the following message may occur:

    Out of Local Memory.  Unable to Recover.

 The error is printed on the screen and the PWB exits to DOS. This
 error may occur when the program list contains too many names. To
 resolve the problem, combine object modules into libraries whenever
 possible. Remove the .OBJ files from the program list and replace them
 with the new libraries. This will reduce the number of object modules
 that need to be defined in the program list.

 Another method that sometimes helps to alleviate the error is to open
 the File menu and close as many unneeded files as possible. This
 should be done before setting the program list.


 42. Situation Where PWB Online Help Text Disappears

 Product Version(s): 1.00 1.10 | 1.00 1.10
 Operating System:   MS-DOS    | OS/2
 Flags: ENDUSER | SR# S901010-118 B_BasicCom S_C B_cobol
 Last Modified: 24-OCT-1990    ArticleIdent: Q66229

 When requesting help in Microsoft Programmer's WorkBench (PWB)
 versions 1.00 and 1.10, the following sequence of events will cause
 the Help screen text to disappear, leaving only the hyperlinks.

 This information applies to Programmer's WorkBench version 1.00 (which
 comes with Microsoft C Professional Development System version 6.00
 for MS-DOS and MS OS/2), and to Programmer's WorkBench version 1.10
 (which comes with Microsoft COBOL Professional Development System
 version 4.00 and with Microsoft BASIC Professional Development System
 (PDS) version 7.10 for MS-DOS and MS OS/2).

 Microsoft has confirmed this to be a problem in PWB. We are
 researching this problem and will post new information here as it
 becomes available.
 Follow these steps to reproduce the problem:

 1. From the DOS or OS/2 prompt, enter PWB. From the File menu, select
    New. Type PLINES and request help by pressing F1 or single-clicking
    the right mouse button.

 2. In the Help dialog, double-click the left mouse button with the
    cursor on the hyperlink "Using PWB Functions."

 3. Double-click the left mouse button with the cursor on the hyperlink
    "PWB Functions by Category."

 4. Double-click the left mouse button with the cursor on the hyperlink
    "Moving Through Files."

 5. The vertical scroll bar will show that you are at the bottom of the
    dialog. Press PGUP and you will notice that the hyperlinks to Up,
    Index, Contents, and Back have disappeared. Double-click the left
    mouse button with the cursor on any of these empty hyperlinks; the
    text on the screen will disappear, with empty hyperlinks appearing
    on the screen.


 43. How to Insert Spaces Before a Block of Text in PWB

 Product Version(s): 1.00   | 1.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | S_EDITOR
 Last Modified: 24-OCT-1990    ArticleIdent: Q66231

 It is sometimes desirable to indent or move over a block of text in
 the Programmer's WorkBench (PWB) or the M Editor. The following steps
 can be used to insert spaces before a block of text to indent it:

 1. Get into boxarg mode. You can select this mode from the Edit menu
    under the Programmer's Workbench, or select the boxstream function
    under the Microsoft Editor.

 2. Highlight the area you want to contain the spaces. This may be
    anywhere in the file.

 3. Select the linsert function. By default, this is CTRL+N.

 The highlighted area should now be moved over and replaced by spaces.

 You don't have to be in boxarg mode for this to work; linsert always
 treats its argument as a boxarg regardless of the current mode.
 However, the highlight on the screen won't match the area that is
 going to be inserted unless you use boxarg mode.

 Also, ldelete can be used to unindent a block of text. However, you
 must be in boxarg or streamarg mode for it to work correctly. In
 linearg mode, it will delete entire lines.


 44. PWB's Use of Expanded Memory

 Product Version(s): 1.00 1.10
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 23-OCT-1990    ArticleIdent: Q66308

 The DOS version of the Programmer's WorkBench (PWB) will utilize
 expanded memory to swap its own segment overlays if it detects that
 expanded memory is available in the system. When PWB needs a new
 overlay, the existing overlay in memory is first copied into expanded
 memory. If there is not enough room in expanded memory to copy the
 overlay, the least recently used overlay is discarded to make room for
 it. This scheme allows most overlays to be read from expanded memory
 instead of from disk.

 Note that this is the only method by which PWB will take advantage of
 available expanded memory, and that PWB versions 1.00 and 1.10 have no
 internal provisions to make use of extended memory in any way.


 45. PWB May Exit to DOS If TMP Not Set Correctly

 Product Version(s): 1.00 1.10
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist1.00 buglist1.10
 Last Modified: 24-OCT-1990    ArticleIdent: Q66309

 If the tmp environment variable is set only to a drive (with no path
 specified), the PWB may "crash" out to DOS when a compile is
 attempted. The screen will still show the PWB, but there will be a
 prompt displayed.

 This problem may be reproduced using the following procedure:

 1. Set up the environment to run the PWB.

 2. Set the tmp environment variable to the current drive, without
    specifying a path. For example:

       SET TMP=C:

 3. Execute the PWB and create or load a simple source file.

 4. Attempt to compile the source file. (Note: If the COMPILE option is
    not available on the make menu, make sure the file has a name with a
    .c extension.)

 Microsoft has confirmed this to be a problem with the Programmer's
 WorkBench versions 1.00 and 1.10. We are researching this problem and
 will post new information here as it becomes available.


 46. MASM Build Switches for PWB 1.10

 Product Version(s): 1.10    | 1.10
 Operating System:   MS-DOS  | OS/2
 Flags: ENDUSER |
 Last Modified:  5-DEC-1990    ArticleIdent: Q66339

 When setting a program list containing .ASM files in Programmer's
 WorkBench (PWB) version 1.10, the following error message occurs:

    Program List: file 'filename' will be ignored
    File type unused by current build options

 The .ASM files are not recognized because PWB 1.10 does not contain
 build switches specific to any language. Build switches are now loaded
 from language extension files (.MXT for DOS and .PXT for OS/2). If you
 have an assembly language extension file, you will not see this error
 message. Language extensions are not necessary and are only a
 convenience for controlling the build process; only the build switches
 are really needed.

 The following build switches can be added to a tagged section in your
 TOOLS.INI file. To use these build options, first choose your language
 options from the Options Build Options menu, then initialize this
 section by typing {arg} tag_name {reinitialize} (type the following to
 invoke the sample build switch below:

    ALT+A asm_rules SHIFT+F8

 These switches can also be added to a custom set of build options
 saved by Save Current Build Options. They may then be initialized by
 choosing Build Options from the Options menu, and then selecting Set
 Initial Build Options to choose the new custom language options.

 Sample Build Switches
 ---------------------

 [pwb-asm_rules]
 ;
 ;   MASM build rules
 ;
 build:macro ASM "MASM"
 build:macro AFLAGS_G "/Mx /T"
 build:macro AFLAGS_D "/Zi"
 build:macro AFLAGS_R ""
 build:inference .asm.obj as_asm_obj
 build:release command as_asm_obj  \
             "$(ASM) $(AFLAGS_G) $(AFLAGS_R) $<, $@;"
 build:debug command as_asm_obj  \
             "$(ASM) $(AFLAGS_G) $(AFLAGS_D) $<, $@;"
 build:include .asm "^[ \t]*include[ \t]+\\([^ \t]+\\)"
 build:include .inc "^[ \t]*include[ \t]+\\([^ \t]+\\)"

 These assembly flags can then be modified from PWB by using the
 following macros. The macros must be assigned to keystrokes to be
 activated. This can be done using the <ASSIGN> pseudo file. They can
 then be used to redefine the flags to pass to MASM.

 ;
 ;   MASM option-setting macros
 ;
 setAFG:= arg "Global MASM Options?"  prompt -> cancel lasttext home \
         "build:macro AFLAGS_G \"" endline "\"" assign

 setAFD:= arg "Debug MASM Options?"   prompt -> cancel lasttext home \
         "build:macro AFLAGS_D \"" endline "\"" assign

 setAFR:= arg "Release MASM Options?" prompt -> cancel lasttext home \
         "build:macro AFLAGS_R \"" endline "\"" assign


 47. Unexpected Behavior with the /Gt Switch and the PWB

 Product Version(s): 1.00   | 1.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | S_C
 Last Modified: 15-JAN-1991    ArticleIdent: Q66828

 Adding the /Gt compiler switch with an argument to the Additional
 Options section of the C Compiler Options on the Programmer's
 WorkBench (PWB) Options menu can cause the value of the argument to be
 changed or dropped.

 Microsoft has confirmed this to be a problem in the Programmer's
 WorkBench version 1.00. We are researching this problem and will post
 new information here as it becomes available.

 When you add the /Gt switch with an argument (for example, /Gt30) and
 click OK, then immediately go back into the Compiler Options dialog
 box; you will see that the /Gt30 switch you just set is now /Gt3.

 If you set a /Gt switch and specify a value, it will compile with that
 correct value because it was written to the file on disk that is used
 to build the program.

 If you go back in and look at the compiler options and see that the
 value is incorrect and Cancel the options dialog, you will still
 compile with your initial correct /Gt value.

 You will compile with the incorrect /Gt value only if you make another
 change in that dialog and select OK. This is because you changed the
 options, so PWB rewrites the options to the file on disk. In the case
 of /Gt, that option is written incorrectly and from that point on, you
 will compile with the incorrect /Gt value.

 Not all values of /Gt are incorrect. The most common incorrect values
 end in zero. The following are examples where the problem occurs:

    /Gt40 will turn into /Gt4
    /Gt0  will turn into /Gt
    /Gt20 will turn into /Gt

 Some other values that get changed are the following:

    /Gt113 will turn into /Gt3
    /Gt305 will turn into /Gt35
    /Gt14  will turn into /Gt4
    /Gt22  will turn into /Gt

 As a possible work around, do not set /Gt in the PWB, and set the
 environment variable CL to the desired threshold, as in the following
 example:

    set cl=/Gt40

 This value will be read by the compiler when it is called from the
 PWB.

 Also, you can set the /Gt switch on the Additional Options line in
 either Set Debug Options or Set Release Options, rather than the
 global Additional Options.


 48. REsearch() Function Prototype Not Found in EXT.H Header File

 Product Version(s): 1.00 1.10 | 1.00 1.10
 Operating System:   MS-DOS    | OS/2
 Flags: ENDUSER | buglist1.00 buglist1.10
 Last Modified:  4-DEC-1990    ArticleIdent: Q67274

 The Programmer's WorkBench (PWB) function REsearch(), although
 included in EXTSUP.LIB, is not prototyped in the EXT.H header file. To
 call REsearch(), use the following prototype:

 int REsearch( PFILE pFile, flagType fForward, flagType fAll,
               flagType fCase, flagType fWrap, char _far *pattern,
               fl *pflStart );

 For more information, see online help.

 Microsoft has confirmed this to be a problem in PWB versions 1.00 and
 1.10. We are researching this problem and will post new information
 here as it becomes available.


 49. PWB Help Crashes When Using "Moving Through a File"

 Product Version(s): 1.10   | 1.10
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | buglist1.10
 Last Modified: 14-DEC-1990    ArticleIdent: Q67361

 When using the online help through the Programmer's WorkBench (PWB),
 the help system will crash if you do the following:

 1. After entering help, choose Contents.

 2. Select the Microsoft Advisor from the list of contents.

 3. Select the Programmer's WorkBench button followed by the "Moving
    Through a File" selection.

 At this point a header will appear on the screen and the elevator for
 the window will appear as though it is at the bottom of a page.

 The page can be scrolled up and the contents viewed, especially if
 highlighted, but the menu items at the top will be blacked out
 (although they are present). From this point, no further help can be
 accessed.

 If you exit help and then reenter, nothing will come up.
 Re-initializing does not reinstate the help system. Only shelling out,
 exiting, and reentering will allow you to access the help system.

 Microsoft has confirmed this to be a problem in the Programmer's
 WorkBench version 1.10. We are researching this problem and will post
 new information here as it becomes available.


 50. PWB Hangs with Novell NetWare

 Product Version(s): 1.00 1.11
 Operating System:   MS-DOS
 Flags: ENDUSER | s_quickc s_codeview s_c
 Last Modified: 14-DEC-1990    ArticleIdent: Q67483

 On certain installations of a Novell network, the network will cause
 the Programmer's WorkBench (PWB) to hang. This problem may also occur
 in CodeView or QuickC. The hang usually occurs when an attempt is made
 to use the mouse.

 If you have a peripheral (such as a mouse) that uses Interrupt Request
 Level (IRQ) 3, and your system is part of a network using Novell
 NetWare version 2.15 or earlier, your system may hang when you load
 QuickC, PWB, or CodeView. As a temporary solution, set your peripheral
 to use another interrupt. For more information, contact your Novell
 NetWare dealer.

 If taking these steps does not solve the problem, please contact
 Microsoft Product Support Services.


 51. PWB Menu Hyperlink in PWB.HLP is Inconsistent in Version 1.10

 Product Version(s): 1.10   | 1.10
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified: 23-JAN-1991    ArticleIdent: Q67614

 When selecting help on the Programmer's WorkBench (PWB) version 1.10
 from the Categories menu in QuickHelp version 1.70, the help screen
 for Microsoft Advisor Help System is presented instead. This behavior
 may be duplicated by following the procedure outlined below:

 1. Start QuickHelp without an argument to get help on any topic. This
    will bring up the main help screen.

 2. Select the Programmer's WorkBench choice under the Categories menu.

 Instead of bringing up the help screen for Programmer's WorkBench, you
 will see the screen for the Microsoft Advisor Help System.

 If the PWB.HLP help file is decoded using helpmake as follows

    helpmake /D /T /Opwb.doc pwb.hlp

 we can see that the reason for this is that the .context directive for
 Programmer's WorkBench appears in the wrong section in the decoded
 help file. The following line

    .context Programmer's Workbench

 appears above the section for "Microsoft Advisor Contents." To correct
 the problem, move the .context directive for Programmer's WorkBench to
 the proper section, which is the "Programmer's WorkBench Contents."

 The helpfile must then be recompressed, as follows:

    helpmake /E7 /T /Opwb.hlp pwb.doc

 The choice of /E7 is shown here for demonstration purposes only, and
 is strictly arbitrary in this case. If maximum compression is desired,
 the numerical argument to the /E switch may be left off, or /E15 may
 be specified. Maximum compression will restore the database as close
 to its original size and state as possible.


 52. "missing ':' in ->" Caused by Control Character

 Product Version(s): 1.00 1.10 | 1.00 1.10
 Operating System:   MS-DOS    | OS/2
 Flags: ENDUSER |
 Last Modified: 14-DEC-1990    ArticleIdent: Q67736

 When invoking the Programmer's WorkBench (PWB), if there is a control
 character at the end of the TOOLS.INI file, [usually a CTRL+Z (ASCII
 26) end-of-file marker] and you only have a [pwb] tagged section, an
 error message will appear stating "missing ':' in ->". Note that the
 "->" is the graphic right-arrow symbol.

 This is not a problem in the PWB. A control character is a legal macro
 name. The message indicates that a macro definition or key assignment
 is expected after the character. To keep this message from appearing,
 place the tag

    [end]

 before the control character at the end of your TOOLS.INI file. With
 this tag at the end of the file, you always suppress the message, even
 if you edit TOOLS.INI with an editor that inserts CTRL+Z's at the end
 of the file. This is because the -> symbol must be within the [pwb]
 tagged section for this error message to be displayed, and the [end]
 tag forces the -> into its own tagged section.

 Simply deleting the control character will work until you edit the
 file with an editor that replaces the CTRL+Z, then this message
 reappears. This may also when using the COPY command to concatenate
 files.


 53. Inconsistent Error Attempting to Load Nonexistent Extension

 Product Version(s): 1.00 1.10
 Operating System:   OS/2
 Flags: ENDUSER |
 Last Modified: 28-DEC-1990    ArticleIdent: Q67777

 When attempting to load a Programmer's WorkBench extension through a
 macro definition in the TOOLS.INI file, if the extension file does not
 exist, or is not in the current path, the following error message is
 displayed in a dialog box:

    pwbhelp:  SYS0123:  A file name or volume label contains an
                        incorrect character

 This error message should indicate that the extension file could not
 be found; however, the message is generated by the OS/2 operating
 system's DLL loading code, and therefore, cannot be changed by PWB.

 The following error message is generated in the DOS version of PWB,
 which displays this message in a dialog box:

    No such file or directory

 To correct the problem, make sure that the directory in which the
 extension resides is in the current path.


 54. PWB May Record Incorrect Paths for Dependencies in Makefile

 Product Version(s): 1.00 1.10  | 1.00 1.10
 Operating System:   MS-DOS     | OS/2
 Flags: ENDUSER | buglist1.00 buglist1.10
 Last Modified:  6-FEB-1991    ArticleIdent: Q67780

 Creating a program list with dependencies in directories other than
 the project (makefile) directory may result in the Programmer's
 WorkBench (PWB) recording the wrong paths to these dependencies.

 The following steps illustrate the problem:

 1. Create subdirectories named TEST and TESTA under the same
    directory, with sample files FOO.C in TEST and GOO.C in TESTA.

 2. Invoke PWB from the TESTA directory.

 3. Create a program list.

 4. Add FOO.C and GOO.C with full path.

 5. Save the list.

 The resulting makefile will contain the line:

    OBJS = goo.c foo.c

 The correct line should read:

    OBJS = goo.c ..\TEST\foo.c

 Changing the location of the project makefile or changing the names of
 the subdirectories will generate the correct paths for dependencies in
 the makefile.

 Microsoft has confirmed this to be a problem in the Programmer's
 WorkBench versions 1.00 and 1.10. We are researching this problem and
 will post new information here as it becomes available.


 55. PWB Extensions in DOS Cannot Shell to DOS

 Product Version(s): 1.00 1.10
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified:  6-FEB-1991    ArticleIdent: Q67792

 Extensions written for the Programmer's WorkBench (PWB) that require a
 call to the operating system do not work correctly under DOS. One
 example of this is the FILTER.C sample extension packaged with
 Microsoft C 6.00.

 When PWB.COM is executed under DOS, it spawns the main editor
 (PWBED.EXE). PWBED.EXE is cleared from memory when a DOS shell is
 executed from within the editor. Once the shell has completed,
 PWBED.EXE is reloaded from disk and initialized. The initialization is
 what causes the problem because it also initializes any extensions to
 the editor at the same time. This means that any information that the
 extension was keeping track of is lost.


 56. Not Enough Core Message Caused by Lack of Memory

 Product Version(s): 1.00 1.10
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified:  6-FEB-1991    ArticleIdent: Q68070

 When loading the Programmer's WorkBench (PWB), a message box may
 appear on the screen containing the message "Cannot Autoload
 Extension, not enough core." The extension file that could not be
 loaded will be indicated. You need to free more memory so that the
 extensions can be loaded.


 57. Windows DLL Build Options Ignore .RC Files in PWB 1.10

 Product Version(s): 1.10   | 1.10
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | buglist1.10 S_C P_WINSDK
 Last Modified: 11-JAN-1991    ArticleIdent: Q68155

 In the Programmer's WorkBench version 1.10, the default build options
 for creating a Windows DLL will ignore any .RC files included in the
 Program List, and therefore, will not build them into the project.

 Use the following steps to correct this problem:

  1. If there is a Program List currently set, clear it.

  2. Set the Main Language to C.

  3. Set the Initial Build Options to Windows DLL.

  4. Create a new Program List containing all the files you want in your
     project.

  5. Save the Program List. At this point, PWB will tell you that your
     .RC file will be ignored. Choose OK when that dialog box appears.

  6. Choose Editor Settings from the Options menu.

  7. Find the line that starts:

        build: target $(PROJ).dll

  8. Change the word "res_dll" on that line to "rc_dll".

  9. Move the cursor off that line to highlight the change. Press SHIFT+F2
     to save the new settings.

 10. Press F2 to exit the ASSIGN pseudofile.

 11. Choose Edit Program List from the Make menu.

 12. Choose Save List. The .RC file will now be saved in the Program
     List and used as expected.

 After these steps are taken, the settings will be saved in the .STS
 file for that project, and will remain correct as long as Set Initial
 Build Options is never selected when this Program List is set. In
 order to keep from repeating these steps for future projects, the
 build options should be saved under a descriptive name, such as
 "Corrected Windows DLL Settings." They can then be chosen for any
 future Windows DLLs.

 Microsoft has confirmed this to be a problem in the Programmer's
 WorkBench version 1.10. We are researching this problem and will post
 new information here as it becomes available.


 58. PWB Build Switch Reference Available as an Application Note

 Product Version(s): 1.00 1.10 | 1.00 1.10
 Operating System:   MS-DOS    | OS/2
 Flags: ENDUSER | appnote softlib SW0330
 Last Modified: 29-JAN-1991    ArticleIdent: Q68367

 The "PWB Build Switch Reference" contains detailed descriptions and
 examples for customizing PWB build switches.

 The Programmer's WorkBench (PWB) can build various types of projects
 based on the information contained in "build switches." These build
 switches are interpreted by PWB in order to create a makefile for a
 project. The switches are normally set for you by PWB for common types
 of projects, but you may define your own build switches to handle an
 advanced project where you require more control over the build
 process. For example, customized build switches will allow you to
 utilize different languages, to incorporate other tools into a
 project, or to build new kinds of targets.

 Although build switch customization is documented in the PWB online
 help, the information is somewhat limited. Therefore, an application
 note was created to cover the customization process in detail. The
 title of this application note is "PWB Build Switch Reference" and it
 can be obtained by calling Microsoft Product Support Services at (206)
 637-7096.

 The "PWB Build Switch Reference" can also be found in the Software/
 Data Library (as file SW0330.ARC) by searching on the keyword SW0330,
 the Q number of this article, or S12875. SW0330 was archived using the
 PKware file-compression utility.

 Note that the application note found in the Software/Data Library is
 an ordinary text file, which lacks the typefaces and formatting of the
 printed version that is available by calling Microsoft Product Support
 Services. Because the printed application note is clearer and easier
 to follow, it is highly recommended that you call for the printed
 version, and that you use the downloaded version only as an interim
 copy.

 Also note that you normally DO NOT need to modify build switches just
 to customize the compile and link operations -- this can generally be
 done by selecting commands from the Options menu. By selecting options
 from the Compile or LINK Options dialog boxes, the correct build
 switches are automatically modified to contain the desired
 information.


 59. Brown Screen Color Changes to Yellow After Running PWB

 Product Version(s): 1.00 1.10
 Operating System:   MS-DOS
 Flags: ENDUSER | s_c buglist1.00 buglist1.10 remapping
 Last Modified:  6-FEB-1991    ArticleIdent: Q69064

 After running PWB, the brown screen color changes to yellow until the
 system is rebooted or the video mode is reset.

 For example, if you run PWB and then run the Microsoft editor, the
 brown characters will appear yellow.

 To work around this problem, you can create a batch file called
 PWB.BAT. In this file, you can start PWB and then reset the video
 mode. For example:

     pwb.bat
             pwb %1 %2 %3 %4
             mode co80,25

 Microsoft has confirmed this to be a problem in PWB versions 1.00 and
 1.10. We are researching this problem and will post new information
 here as it becomes available.


 60. Reinitializing After Changing Editor Settings Is Very Slow

 Product Version(s): 1.10   | 1.10
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified: 11-FEB-1991    ArticleIdent: Q69142

 The current editor settings in the Programmer's WorkBench (PWB) may be
 changed by choosing Editor Settings from the Options menu, making a
 change to the <assign> pseudofile, and then saving that file. If
 SHIFT+F8 (initialize) is pressed while the <assign> pseudofile is
 still displayed, PWB may appear as though it is hung; it is actually
 reinitializing each statement of the editor settings (<assign>)
 pseudofile.

 The following steps will reproduce this behavior:

 1. Enter PWB and select the Options menu.

 2. Choose the Editor Settings menu.

 3. Make a change in the <assign> pseudofile and then save it.

 4. Press the "initialize" keystroke combination (SHIFT+F8) and a popup
    box will appear stating "reinitializing...". The reinitialization
    is actually taking place but it is very slow because PWB is
    rebuilding the <assign> pseudofile for each entry in your TOOLS.INI
    file.

 This behavior does not occur in PWB version 1.00. Version 1.10
 includes a change to the earlier version; you can see a new assignment
 (made via "arg textarg <assign>") immediately updated if you are
 viewing the <assign> pseudofile.

 This is expected behavior because the <assign> pseudofile is meant to
 show the settings that were in effect at the time the file was
 displayed. It is not recommended that it be dynamically updated except
 via the mechanism of actually editing the file. If you changed a
 setting via "arg textarg assign" (ALT+A textarg ALT+=), a better way
 to view your new setting(s) is by using "refresh" (SHIFT+F7), or by
 switching away and back again via "setfile" (F2).


 61. PWB Ignores Certain Compiler Switches in Additional Options

 Product Version(s): 1.00 1.10 | 1.00 1.10
 Operating System:   MS-DOS    | OS/2
 Flags: ENDUSER | s_c
 Last Modified: 25-FEB-1991    ArticleIdent: Q69145

 The compiler switches

    /Fo, /Fe, /F hexnum, /Fm, and /link link-info

 are ineffective when entered in the Additional Options field of the C
 Compiler Options dialog box from the Options menu of the Programmer's
 Workbench (PWB). This is the intended behavior. The functionality of
 all of these switches is provided through the Compiler, Link, and
 Build Options dialog boxes from the Options menu.

 The /Fo switch is overridden by PWB as it creates the .MAK file needed
 to build the project. To perform this function correctly:

 1. Set a program list from the Make menu.
 2. Choose Build Options from the Options menu.
 3. Choose the Build Directory button.
 4. Enter the destination path in that field, such as:

       C:\C600\PROJECT\

 5. Rebuild the project, and both the .EXE and .OBJ files will be placed
    in that directory.

 The other switches are used only to pass information to the linker
 when the CL command is used outside PWB without the /c option. Because
 PWB always compiles and links separately, these switches are lost. To
 utilize these switches from within PWB, select the appropriate options
 in the Link Options dialog box from the Options menu.


 62. How to Increase the Size of the PWB Build Status Box Under DOS

 Product Version(s): 1.00 1.10
 Operating System:   MS-DOS
 Flags: ENDUSER | window dialog
 Last Modified: 22-FEB-1991    ArticleIdent: Q69475

 In the DOS version of the Microsoft Programmer's WorkBench (PWB)
 versions 1.00 and 1.10, the status box displayed in the center of the
 screen during a compile can be made larger by increasing the length of
 the command being executed.

 When Build or Rebuild All is selected from the Make menu in PWB, a
 build status box appears on the screen showing the command currently
 being executed. Unfortunately, this box is often too small and the
 current command being displayed gets truncated. One way to increase
 the size of this box is to increase the length of the NMAKE command
 line.

 To increase the length of the NMAKE command line, add the following
 text (without the quotation marks) to the NMAKE Options dialog box,
 which can be selected from the Options menu:

    "                                                /NOLOGO"

 Be sure to include the spaces when you type this line. Then, when you
 select Build or Rebuild All from the Make menu, the build status box
 will be almost as wide as the screen, allowing most of the subsequent
 commands to fit completely into the box.

 If you use the PWB "compile" command, or choose the Compile File
 option from the Make menu, the build status box behaves similarly --
 the longer the command to be executed command, the larger the box will
 be.






 Microsoft CodeView
 =============================================================================


 1. Sequential Mode Not Available in CodeView Version 3.00

 Product Version(s): 3.00 3.01 3.11  | 3.00 3.01 3.11
 Operating System:   MS-DOS          | OS/2
 Flags: ENDUSER |
 Last Modified:  6-FEB-1991    ArticleIdent: Q69065

 The CodeView sequential mode (/T option) is not available in CodeView
 version 3.00.

 In CodeView versions 2.30 and earlier, the /T option caused the
 debugger to operate in "sequential mode," which means that only a
 command-line interface was available. You could then type the command
 "=COM1" to redirect the input and output to the COM port, which
 allowed debugging via a remote terminal.

 The /T option and the "=COM1" command are not available in CodeView
 3.00, 3.10, and 3.11 because of the new windowing environment used in
 these versions.

 However, you can still redirect CodeView output to COM1 using the
 Redirected Output command.

 The Redirected Output command causes the CodeView debugger to write
 all subsequent command output to a device, such as another terminal, a
 printer, or a file. The term "output" includes not only the output
 from commands but also the command characters that are echoed as you
 type them.

 The second greater-than symbol (optional) appends the output to an
 existing file. If you redirect output to an existing file without this
 symbol, the existing file will be replaced. For example:

    >>COM1

 In the example above, output is redirected to the device designated as
 COM1 (probably a remote terminal). You might want to enter this
 command, for example, when you are debugging a graphics program and
 want CodeView commands to be displayed on a remote terminal while the
 program display appears on the originating terminal.

    >>OUTFILE.TXT

 In the example above, output is redirected to the file OUTFILE.TXT.
 This command is helpful in keeping a permanent record of a CodeView
 session.


 2. How Interrupts Are Handled in CodeView

 Product Version(s): 1.00 1.10 2.00 2.10 2.20 2.30
 Operating System:   MS-DOS
 Flags: ENDUSER | TAR55548
 Last Modified:  9-AUG-1989    ArticleIdent: Q11817

 Question:

 How does CodeView handle interrupt vectors? Does it mask any
 interrupts when it runs?

 Response:

 CodeView saves and restores about 60 interrupt vectors as a safety
 feature. However, it only redirects the following nine vectors for its
 own use:

    0       Divide By 0
    1       Single Step
    2       NMI
    3       Breakpoint
    9       Keyboard
    21H     DOS functions
    22H     DOS terminate
    23H     ^C
    24H     Critical Error

 The remaining estimated 51 vectors are never altered by CodeView
 unless something else (e.g. the program being debugged) alters them
 after CodeView has started up. In this case, CodeView restores them to
 their original value as it exits.

 When you enter G(o) and let your program run, CodeView relinquishes
 control and lets all interrupts (except the nine listed above) flow
 into your application for processing. However, when you hit a
 breakpoint, the 8259 Programmable Interrupt Controller is masked. This
 prevents interrupts from coming into your application while your
 program is suspended. If you enter G(o) again, CodeView reenables
 interrupts to your application.

 To avoid a bug in the 8086 family, CodeView masks the interrupt
 controller during T(race) commands and some P(rogram step) commands.
 CodeView Versions 2.00 and above solve this restriction by emulating
 the interrupts for your application.

 You normally do not single-step or trace real-time code, so this
 should not be a problem for developers writing interrupt-driven code.
 However, it is something you should be aware of if you are depending
 on interrupts to get to your application. For example, it will not
 work if you enter "T 1000" and expect your program to catch and
 process interrupts during the trace. You will need to set a breakpoint
 at the instruction with which you are concerned, then enter G(o).


 3. Debugging Routines That Are in Libraries

 Product Version(s): 1.00 1.10 2.00 2.10 2.20 2.30 | 2.20 2.30
 Operating System:   MS-DOS                        | OS/2
 Flags: ENDUSER | TAR55321
 Last Modified: 21-AUG-1989    ArticleIdent: Q11877

 Question:

 When CodeView attempts to debug a function from a library module, it
 is unable to find the source even when that module was compiled with
 -Zi. It prompts me to "Enter Directory for Program (CR for None)?". I
 enter the directory in which PROGRAM.C resides, but CodeView cannot
 find it. Is there any solution other than not placing modules I wish
 to debug in libraries?

 Response:

 This is a consequence of the way the LIB utility works. When adding an
 object module to a library, LIB records only the source file's base
 name, not its extension. Therefore, "c:\c\source\module1.c" becomes
 "c:\c\source\module1" (no extension). When you are debugging an
 application that calls "module1", CodeView attempts to find
 "c:\c\source\module1". However, it does not accept the filename you
 give because the file is really named "module1.c".

 One way to work around this restriction is to rename your source file
 from "c:\c\source\module1.c" to "c:\c\source\module1" (no extension)
 after you have compiled it and put it into a library. This way, the
 actual name will match the name CodeView is searching for.

 Another solution is to use Library Manager Version 3.07 (which came
 with MASM 5.00) or later; this solves the problem by not stripping the
 file's extension as it is put into a library.


 4. CVP May Generate a Trap B with Large Programs Under OS/2 1.30

 Product Version(s): 2.20 2.30 3.00 3.10 3.11
 Operating System:   OS/2
 Flags: ENDUSER | gp fault protection violation
 Last Modified: 25-FEB-1991    ArticleIdent: Q69348

 Debugging a large application with CodeView under OS/2 version 1.30
 may result in a Trap B system error. Trap B is a "segment not present"
 exception, which results from changes that were made to this version
 of the operating system.

 In version 1.30 of OS/2, the code for DosPTrace() was made swappable,
 while in previous versions it was not. DosPTrace() is part of the OS/2
 API that allows a parent process to control the execution of a child
 process, and to access the child process's memory directly to insert
 breakpoints or change data.

 Because CodeView relies heavily on DosPTrace(), problems arise if this
 code is swapped from memory. The majority of problems occur when
 execution reaches a breakpoint while the DosPTrace() code is not
 present; control should then jump to code that is not currently in
 RAM.

 Because large programs (or heavily loaded systems) tend to result in
 more swapping, this problem appears much more readily when debugging
 large applications.

 The only sure workaround for this problem is to turn off swapping
 while debugging, but it also may help to increase or free up available
 memory. To disable swapping, modify the MEMMAN switch in CONFIG.SYS as
 follows:

    MEMMAN=NOSWAP

 To increase available memory, either install more memory in the
 computer itself or terminate all other unnecessary processes before
 debugging (to remove them from memory).

 This problem is the result of a design change with OS/2 1.30 and is
 not a problem with CodeView. This change is being reconsidered for
 future versions of OS/2. New information will be posted here as it
 becomes available.


 5. Using Two Monitors with CodeView

 Product Version(s): 1.00 1.10 2.00 2.10 2.20 2.30 | 2.20 2.30
 Operating System:   MS-DOS                        | OS/2
 Flags: ENDUSER | TAR56465
 Last Modified: 11-SEP-1989    ArticleIdent: Q11966

 Question:

 How do I use CodeView with two monitors? Where is this option
 documented?

 Response:

 Invoke CodeView with the following command:

    CV /2 PROGRAM

 This command tells CodeView to put its display on your secondary
 monitor and lets your program's output go to the default display. This
 option is documented in the "CodeView Options" section of the
 "Microsoft CodeView and Utilities Software Development Tools for the
 MS-DOS Operating System" manual in all products except Microsoft C
 Version 4.00, where it is documented in the README file.

 You must have two monitors and two display adapters to use this
 feature. You must have a monochrome and a non-monochrome monitor;
 because a monochrome monitor's video memory is in a different
 location than a CGA, EGA, or VGA's. This is how CodeView implements
 the /2 option, by writing to both sets of video memory.

 When you use the /2 option, your program's display appears on the
 current default adapter and monitor, while the debugging display
 appears on the secondary adapter and monitor. You can switch which
 monitor is the current default adapter with the MS-DOS MODE command.
 "MODE MONO" causes standard output to go to the MDA, while "MODE CO80"
 causes standard output to go to your CGA, EGA, or VGA.

 For example, if you have both a CGA and an MDA, you might want to set
 the CGA up as the default adapter. You could then debug a graphics
 program with the graphics display appearing on the graphics monitor
 and the debugging display appearing on the monochrome adapter.


 6. /L Must Give Full Pathname to .DLL Unless in Current Directory

 Product Version(s): 2.20 2.30 | 2.20 2.30
 Operating System:   MS-DOS    | OS/2
 Flags: ENDUSER |
 Last Modified: 16-AUG-1989    ArticleIdent: Q47937

 When debugging dynamic link modules with CodeView Protect (CVP), you
 must use the /L switch. Before invoking CVP, make certain that the
 .DLL is in the LIBPATH specified in the CONFIG.SYS file. When invoking
 CVP with the /L switch, if the .DLL is not located in the current
 directory, you must specify the full drive and pathname to the DLL. An
 example is the following:

    CVP /L d:\os2\dll\stdll.dll stmain.exe

 In this example, the full drive and pathname are given for the DLL to
 be debugged. If the full pathname is not given, CodeView will come up.
 However, you will be unable to step into the DLL. CodeView will simply
 step over that call.


 7. CodeView Cannot Trace into Single-Line Functions

 Product Version(s): 2.20 2.30 | 2.20 2.30
 Operating System:   MS-DOS    | OS/2
 Flags: ENDUSER |
 Last Modified: 15-SEP-1989    ArticleIdent: Q47624

 CodeView Versions 2.20 and 2.30 do not trace into a function that is
 contained in a single line of code. For example, if the following
 program is compiled and loaded into CodeView, an attempt to trace into
 the function funct() results in the trace stepping over the function,
 rather than tracing into it.

 Sample Program
 --------------

 /* SIMPLE.C ... a very simplistic sample program                    */

 int funct(void);
 int x;

 void main(void)
 {
   x = funct()
  }

 /* single-line function. It does nothing more than return a value.  */

 int funct(void){return 1;}

 If the above function is modified so that it performs exactly the same
 task but is located on multiple lines, as follows, then CodeView
 handles it correctly:

 int funct(void)
  {
    return 1;
   }



 8. Trace Stops on Line Following a Loop Before Loop Is Done

 Product Version(s): 2.20 2.30 | 2.20 2.30
 Operating System:   MS-DOS    | OS/2
 Flags: ENDUSER | S_C
 Last Modified: 15-SEP-1989    ArticleIdent: Q47625

 In trace mode, CodeView stops on the line following a loop that does
 not have open and close braces ({}), before the loop is done.

 When tracing through a loop without the braces ({}), the trace stops
 on the statement immediately following the loop each time through the
 loop, giving the impression that the statement is being executed
 inside the loop. Actual program execution is correct.

 The following program was compiled with C Version 5.10 with the
 command line

    cl /Zi /Od program.c

 and run using CodeView 2.20, as follows:

     cv program.exe

 The trace stops at the printf each time through the loop even though
 printf is not part of the loop, but does not print anything until the
 end of the program.

 Sample Program
 --------------

 #include <stdio.h>

 void main(void)
 {
     int i;
     int count;

     count = 0;

     for(i=0;i<3;i++)
         if(i)
             count++;

     printf("Count is %d\n",count);
 }


 9. The 37th Call Added to the Calls Menu Corrupts CodeView Screen

 Product Version(s): 2.20   | 2.20
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | buglist2.20 fixlist2.30
 Last Modified: 10-NOV-1989    ArticleIdent: Q50496

 The CodeView Calls menu shows the current depth of function calls as
 well as the line number the routine was called from and the parameters
 passed. The current routine is always at the top and the routine from
 which the current routine was called is directly below.

 The routines in the Calls menu are first labeled 0-9, and if you are
 nested more than ten levels deep, CodeView labels the next 26 calls
 A-Z, for a display that can accept 36 levels of subroutine calls. If
 you exceed this limit and then select the Calls menu, the CodeView
 display becomes corrupted.

 If the display is corrupted in this manner, the Redraw ("@") dialog
 command can be used to restore the display to it's original state.

 The Stack Trace dialog command (K) has the same function as the Calls
 menu and correctly handles nesting of more than 36 levels deep.

 Microsoft has confirmed this to be a problem with CodeView Version
 2.20. This problem was corrected in Version 2.30.


 10. Quickwatch Seems to Hang When Expanding Very Large Arrays

 Product Version(s): 3.00 3.10 3.11 | 3.00 3.10 3.11
 Operating System:   MS-DOS         | OS/2
 Flags: ENDUSER | s_quickc
 Last Modified:  6-FEB-1991    ArticleIdent: Q68010

 When expanding an element in a large array (usually greater than 1000
 elements, but system dependent), the quickwatch function appears to
 hang. This apparent problem is caused by the time it takes to re-align
 the data in the window, and is actually normal operation. If you place
 the same array element in the Watch Window, it will expand instantly.


 11. Structures Declared with Near, Far, Pascal, and Fortran

 Product Version(s): 2.20 2.30 | 2.20 2.30
 Operating System:   MS-DOS    | OS/2
 Flags: ENDUSER | S_C S_QuickC buglist2.20 buglist2.30
 Last Modified: 16-AUG-1989    ArticleIdent: Q47694

 CodeView is unable to display elements of structures declared with the
 following keywords:

    near
    far
    pascal
    fortran

 Using ?? to display a structure yields the structure table with only
 one value inside. This value is the first element in the structure.
 Using w? or ? yields the following error message:

    Operand types incorrect for this operation

 Microsoft has confirmed this to be a problem with CodeView Versions
 2.20 and 2.30. We are researching this problem and will post new
 information as it becomes available.

 To work around this problem, recompile without these keywords, or
 obtain the address of the structure element and put a watch on the
 memory location.

 Consider the following large model program:

 struct { int x;
          int y;
          int z;} near a;    /* or far, pascal, fortran */

 void main(void)
 {
   a.x = 1;
 }

 To put a watch on a.x, you could issue the following commands:

 ? &a
 0x0345:0000       <- result is the address of the structure
 ww 0x0345:0x0     <- address of x
 ww 0x0345:0x2     <- address of y (two byte int from x)

 This puts a watch on the first and second elements (x and y) in the
 structure.


 12. Older Vega VGAs Hang CodeView When in VGA Mode

 Product Version(s): 2.10 2.20 2.30 | 2.20 2.30
 Operating System:   MS-DOS         | OS/2
 Flags: ENDUSER |
 Last Modified: 14-AUG-1989    ArticleIdent: Q27212

 Question:

 Why does my old Vega VGA card cause CodeView to hang when I start it
 in VGA mode? It works properly when I start CodeView when the card is
 in CGA mode.

 Response:

 Some of the older Vega VGAs do not work correctly with CodeView. The
 Vega VGA card uses the same maskable interrupt for detecting graphics
 mode as CodeView.

 We recommend that you contact Vega by calling 1 (800) 248-1850 for
 advice if you experience this problem.


 13. Ambiguous Documentation of Enter ASCII (EA) Command

 Product Version(s): 2.10 2.20 | 2.10 2.20
 Operating System:   MS-DOS    | OS/2
 Flags: ENDUSER |
 Last Modified: 16-AUG-1989    ArticleIdent: Q47764

 In the "Microsoft C 5.1 Optimizing Compiler" manual, the "CodeView and
 Utilities" section does not thoroughly document the EA command for
 CodeView. The following is a more complete explanation:

    EA address [list]

    The Enter ASCII (EA) command modifies array to the value of [list].
    Address refers to what you want to modify. [list] refers to a
    string literal such as "hello". EA will copy [list] to array. Thus,
    if you specify address by giving an array, such as an array of
    characters, the array will have [list] copied into it. However, if
    you were to give a pointer to a character, then the bytes that make
    up the pointer will be directly modified, not the block of memory
    the pointer is pointing at.

 Consider the following examples:

 char array[] = "Hello";
 char *ptr    = "Hello";

 >EA array "Hi"
 >EA ptr   "Hi"

 The result is that the array would contain "Hillo", and ptr will be
 pointing to some unknown memory location.

 The array is considered a constant pointer to a block of memory, and
 as such, any operations on it can only affect the block of memory.
 However, ptr is a variable; therefore, any operations on it affect the
 value of ptr, which happens to be a two- or four-byte number. That
 number happens to refer to a location in memory.

 If you want to changed the block of memory that ptr points to, you
 must do the following:

    >EA &ptr[0] "Hi"

 Essentially, this takes the address of the character that ptr is
 pointing at, gives a constant address, and thus modifies the block of
 memory there. To clarify, imagine you have a character located some
 place in memory. To move a character, you must make a copy of it to
 some other memory location; it is not possible to take its address and
 modify the address directly to change where the character is located.
 Thus, the address of that character is always a constant value. ptr[0]
 happens to be a character located someplace in memory. As such, the
 address of that specific character is a constant value. Since a
 constant cannot be modified, EA changes the block of memory starting
 at where the constant pointer is pointing.


 14. Debugging of DLLs That Do Not Have the .DLL Extension

 Product Version(s): 2.30   | 2.30
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified: 21-AUG-1989    ArticleIdent: Q47938

 CodeView Protect (CVP) Version 2.30 has the ability to debug DLLs that
 are called with DosLoadModule(). DosLoadModule() can load DLLs that
 do not have the .DLL extension. However, CVP 2.30 cannot debug DLLs
 that do not have the .DLL extension. If you want to debug DLLs that
 are called with DosLoadModule, they must have the .DLL extension.

 Microsoft is aware of this limitation with CodeView Protect 2.30. We
 are researching this problem and will post new information as it
 becomes available.


 15. Resident Software May Cause "Internal Debugger Error 80"

 Product Version(s): 1.x 2.00 2.10 2.10 2.30
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 29-AUG-1989    ArticleIdent: Q47989

 Question:

 Sometimes when I run CodeView, I get an "Internal Debugger Error 80"
 message. What causes this?

 Response:

 Internal Debugger Error messages are usually caused by problems in
 your MS-DOS environment; the most likely cause is the presence of
 memory-resident software, commonly referred to as TSRs (terminate-
 and-stay-resident software).

 For example, running CodeView with Borland's Sidekick loaded has been
 known to cause "Internal Debugger Error 80" and "R6002: Floating Point
 not loaded" error messages. "Internal Debugger Error 80" has also been
 reported when CodeView was run with Software Solutions' "Software
 Carousel" loaded into memory.

 CodeView Versions 2.00 and later have become increasingly more
 sensitive to TSRs. If you receive an Internal Debugger Error message,
 or you are experiencing strange problems within CodeView, make sure
 you are running CodeView with no memory-resident software loaded
 (including, but not limited to, device drivers, screen savers,
 keyboard enhancers, command-line editors, etc.). Disabling your
 resident software, but not rebooting, may not completely remove its
 interference, so be sure to "boot clean" when trying to resolve a
 problem of this type.

 If you continue to receive the error message without memory-resident
 programs, try running CodeView on some other program to see if the
 error is related to particular code. If the error is related to the
 specific code, and you are unable to determine the cause, you may want
 to call Microsoft Product Support for assistance at (206) 454-2030.

 If the error is not dependent on your code, the problem might be the
 particular sequence of CodeView commands you execute. Make a note of
 what operations you performed, i.e., the sequence of Trace, Go, Watch,
 Tracepoint, etc., commands that were issued, and contact Microsoft
 Product Support via phone, letter, or Microsoft OnLine.


 16. CVP Restart Command (Dialog Version) Doesn't Properly Set argc

 Product Version(s): 2.20 2.30 | 2.20 2.30
 Operating System:   MS-DOS    | OS/2
 Flags: ENDUSER | buglist2.20 buglist2.30
 Last Modified: 28-AUG-1989    ArticleIdent: Q48000

 When using the dialog version of the Restart command, you can restart
 your program with command-line arguments; however, under CodeView
 Protect (CVP) Versions 2.20 and 2.30, argc does not get properly set.

 The Dialog Restart command is often used to restart a program with
 command line arguments. For example, you could use the following:

    L arg1 arg2 arg3

 This example restarts the current executable file, retaining any
 breakpoints, watchpoints, and tracepoints, with arg1, arg2, and arg3
 loaded into argv[1], argv[2], and argv[3], respectively. Argv[0] is
 always set to the name of the current executable file. Argc, at this
 point, should be set to four. The problem presents itself here; argc
 either remains unchanged from the value it was initially set to when
 CodeView was started, or is decremented by one. If, for example,
 CodeView is started with two command-line arguments (argc would then
 be set to three) and then executed, the previous example argc (which
 should then set argc to four) would remain unchanged. When using the
 Dialog Restart command and specifying fewer arguments than were
 specified at start up, argc sometimes is decremented by one.

 Microsoft has confirmed this to be a problem with CodeView Versions
 2.20 and 2.30. We are researching this problem and will post new
 information as it becomes available.


 17. Cannot Load CTRL+Z-Terminated Files with Less than 129 Bytes

 Product Version(s): 1.00 1.10 2.00 2.10
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist1.00 buglist1.10 buglist2.00 buglist2.10 qfbv
 Last Modified:  4-NOV-1988    ArticleIdent: Q26548

 Problem:

 When using the F(ile) O(pen) command to load a text file which has
 less than 129 bytes and is terminated with a hex 1A (decimal 26,
 CTRL+Z, EOF), CodeView issues the error message "Not a text file." If
 the CTRL+Z character is removed, or if the file size is 129 bytes or
 greater, CodeView has no problem loading it.

 Response:

 Microsoft has confirmed this to be a problem in Version 1.00, 1.10,
 2.00, and 2.10. We are researching this problem and will post new
 information as it becomes available.


 18. Debugging High Resolution EGA or VGA Graphics

 Product Version(s): 1.00 1.10 2.00 2.10 2.20 2.30 | 2.20 2.30
 Operating System:   MS-DOS                        | OS/2
 Flags: ENDUSER | TAR61178
 Last Modified: 14-AUG-1989    ArticleIdent: Q23308

 Question:

 I am trying to debug a program that does EGA or VGA graphics. When I
 continue from a breakpoint after the program has painted the screen,
 the screen is not as it was before the breakpoint. I think that all
 colors have been turned to black, but I am not sure.

 I tried this procedure with no switches, with /s, and with /t. The
 program is using the EGA in 640x350 16-color mode. Is this supposed to
 work? If it does not work, why not? What will you do about supporting
 the higher modes for the new machines such as the Personal System 2
 series from IBM?

 Response:

 This behavior is partly related to the size of the buffer that
 CodeView creates for storing screen information. If you are running on
 a CGA, EGA or VGA board, this buffer is by default 16K. If you are running
 on a monochrome board, this buffer is by default 4K. As you are
 finding, 16K is simply not enough memory for a color image using
 640x350 resolution (the maximum resolution supported would be
 640x200).

 One of the reasons why CodeView does not have the ability to handle
 the buffer requirements of an EGA image is that the EGA registers are
 write only. There is no way for CodeView to detect what mode the EGA
 currently is in so it can adjust the size accordingly. Also note that
 with the different resolutions the image is stored in different memory
 locations. The black on black characters may simply be a blank image
 because CodeView cannot tell that the resolution is different and
 therefore the image is located elsewhere.

 With the PS/2 machines this is not an issue because the EGA registers
 have read capability. We are reviewing this with regard to future
 implementations of CodeView.

 The following are some ways to work around this current limitation:

 1. Try writing a routine that will place the display in the desired
    mode before you invoke CodeView. CodeView will be able to judge
    which mode is currently in effect and can locate the image in the
    correct area of memory. Note that the image will not be displayed
    in color. You will only see the higher resolution since the buffer
    is not big enough.

 2. Debug your applications that run in high resolution graphics with a
    second monitor (use the /2 switch). Since the display is going to a
    different screen, CodeView will not have to worry about changing
    the video modes or the buffering.


 19. CodeView Version 2.20 Is Called CVPCK.EXE by DOS Version 2.10

 Product Version(s): 2.20
 Operating System:   MS-DOS
 Flags: ENDUSER | CV CVPCK CVPACK 2.x
 Last Modified: 21-SEP-1989    ArticleIdent: Q48689

 Question:

 When trying to invoke CodeView Version 2.20 under DOS Version 2.10 or
 2.11, I get the messages "Cannot Find CVPCK.EXE" and "Please enter new
 program spec:". How can I get CodeView 2.20 to work under DOS Versions
 2.1x?

 Response:

 If you rename CV.EXE to CVPCK.EXE, you can run CodeView Version 2.20
 under DOS Version 2.10 or 2.11. You must also rename CV.HLP to C.HLP
 to make the on-line help accessible.

 CodeView Version 2.20 is included with C Version 5.10, FORTRAN Version
 4.10, Pascal Version 4.00, and Macro Assembler (MASM) Version 5.10.

 Many people mistakenly assume that CodeView is actually looking for
 CVPACK.EXE, which also comes with the software packages listed above.
 If you rename CVPACK.EXE to CVPCK.EXE and then try to run CVPCK.EXE,
 you will receive the error message "overlay not found." If you receive
 this error, delete CVPCK.EXE, copy both CV.EXE and CVPACK.EXE from the
 installation disks, and follow the instructions above.

 Under DOS Versions 3.x, a C program's name is available from argv[0].
 Under DOS Versions 2.x, argv[0] always equals the letter "C", so
 programs that need to find themselves under DOS Versions 2.x also have
 their own names hard coded as the filename to locate. Unfortunately,
 the hard-coded name within CodeView Version 2.20 is "CVPCK.EXE", so
 this is what it looks for under DOS Versions 2.x.


 20. CodeView String Search Length Limited to 19 Characters

 Product Version(s): 2.10 2.20 2.30 | 2.10 2.20 2.30
 Operating System:   MS-DOS         | OS/2
 Flags: ENDUSER | SR# G890810-24574 P_WinSDK
 Last Modified: 19-SEP-1989    ArticleIdent: Q48863

 CodeView Versions 2.20 and 2.30 and CodeView for Windows Version 2.10
 have a 19-character limit in the "Find..." option of the Search menu,
 even though the dialog box is much longer than 19 characters. Entering
 a search string longer than 19 characters results in one of two error
 messages.

 If the search string entered is 20 or 21 characters long, CodeView
 displays the erroneous message "No match of regular expression," even
 if the search string does exist in the file. If the search string is
 22 characters or more in length, CodeView displays the more
 appropriate message "Regular expression too long."

 Although 19 characters sometimes can be limiting, CodeView does
 substring searches so that searching for the following

    AFunctionWithAVeryL

 finds the following string:

    AFunctionWithAVeryLongName

 You will have problems only if you have both of the following and
 you are trying to locate one, but not the other:

    AFunctionWithAVeryLongName()
    AFunctionWithAVeryLongParameterList(a,b,c,d,e,f,g,h,i,j)

 In this case, you won't be able to specify search strings long enough
 to distinguish between the two. However, you can repeatedly use the
 Next command from the Search menu to find the next occurrence of the
 following:

    AFunctionWithAVeryL

 The Next command will find whichever of the above two function names
 that comes next in the source file.


 21. Files, Environment Inaccessible Only While Running under CVP

 Product Version(s): 2.20
 Operating System:   OS/2
 Flags: ENDUSER |
 Last Modified: 30-NOV-1989    ArticleIdent: Q49313

 Due to combined problems in both protected-mode CodeView (CVP) Version
 2.20 and OS/2 Version 1.00 or 1.10, programs that correctly access
 data files and/or system environment information could fail when
 attempting this same access while running under CVP 2.20. This is
 strictly a protected-mode problem and is unrelated to the use of
 CodeView under MS-DOS. The sample program at the end of this article
 can be used to demonstrate this problem.

 The system environment information includes such items as the path and
 other environment variables, as well as the current working directory
 for each disk drive. This information is normally available to an
 executing program, but for a program being debugged with CVP 2.20
 running under OS/2 1.00 or 1.10, most of this environment information
 is inaccessible.

 This inaccessibility is a result of environment handling problems in
 both CVP 2.20 and OS/2 Version 1.00. Since CodeView is run from the
 command prompt, all the current environment information is available
 to CodeView itself, but the program being debugged is given its own
 new screen group in which to run. It is in this new screen group that
 the current environment information is lost because it is not carried
 over by either OS/2 or CodeView.

 Although the OS/2 problem has been corrected in Version 1.10, the
 CodeView problem still prevents access to the environment. Therefore,
 upgrading either CodeView or OS/2 alone does not solve the problem.
 Only with CodeView Version 2.30 running under OS/2 Version 1.10 is the
 problem eliminated.

 There may be some environment information available to the program
 being debugged, but only if it was set in the CONFIG.SYS file at start
 up. Since each new screen group is begun with a copy of the original
 start-up system environment, any SET commands carried out in the
 CONFIG.SYS file will then be duplicated for all subsequent screen
 groups.

 Otherwise, if a program needs access to environment variables that
 were set in the current screen group where CodeView will be invoked,
 then the only way to make the information available while debugging is
 to temporarily hard code the information into the program. After
 debugging, the program can be changed back to using the actual
 environment strings.

 The only other alternative to temporarily hard code the environment
 information into the program is to set the environment variables in the
 CONFIG.SYS file at boot time, rather than setting them in the current
 screen group.

 The only reason a file access will fail only while the program is
 running under CodeView is if the program is assuming the file is in
 the current working directory on the current or another drive.

 If this is the case, then one of the following workarounds may be used
 to gain access to files while debugging:

 1. Use full pathnames for all file accesses, since this alleviates any
    dependency on knowing the current working directory for the drive
    that is being accessed. If it is not feasible to have hard-coded
    pathnames in the completed program, at least adding the full paths
    temporarily will allow debugging.

 2. Put the files to be accessed in the root directory of the boot
    drive. This allows them to be found even under CodeView because
    with no environment information, the current working directory
    defaults to the root of the boot drive.

 3. Use a two-monitor debugging setup and start CodeView with the /2
    option. In this situation, CVP does not need to start a new screen
    group for the program being debugged because it can run it on the
    second monitor. Thus, the current environment information is
    available to both programs because they are both running in the
    current screen group.

    For more information about debugging with a two-monitor setup, query
    on the following:

       CodeView two monitor debugging

 The following C program can be used to demonstrate this environment
 problem:

 Program Example:
 ---------------

     /* TEST.C - shows inaccessible files under CodeView

        Compile with : CL /Zi /Od test.c
        Run with : test <filename>      where <filename> is any file
                        in the current directory.  The file will be
                        opened properly.
        Begin CVP with : CVP test <filename>     where <filename> is
                        the same as before. The file will not be
                        found when the program is run or traced.
     */

     #include <stdio.h>
     void main(int, char *[]);

     void main(int argc, char *argv[])
     {
         FILE *dfile ;

         if ((dfile = fopen(argv[1], "rb")) == NULL) {
             perror ("") ;
             printf ("Cannot open file '%s'.\n\n", argv[1]) ;
         }
         else {
             printf("File %s opened OK.\n\n", argv[1]) ;
             fclose (dfile) ;
         }
     }


 22. COM Port Time-Out Halts Redirection of CVP to Remote Terminal

 Product Version(s): 2.20 2.30
 Operating System:   OS/2
 Flags: ENDUSER |
 Last Modified: 27-OCT-1989    ArticleIdent: Q49376

 When using protected-mode CodeView (CVP) under OS/2, there is a
 problem with the serial communications (COM) ports timing out after 60
 to 90 seconds of inactivity. This time-out makes it essentially
 impossible to do remote terminal debugging with CVP. Once the time-out
 occurs, no further input is accepted from the remote terminal. The
 only workaround is to quit CodeView and begin again, or to do a break
 and then restart the redirection to the COM port.

 The CodeView Debugger allows redirection of input and output to a file
 or device. This procedure is commonly used to set up a remote (dumb)
 terminal for CodeView input and output, while the PC screen is used
 for displaying the program input and output. The terminal is connected
 through a COM port, which eliminates the need for a second video
 adapter as is required when using two monitors with the /2 option.
 Entering "=COM1" at the CodeView command prompt enables input and
 output redirection to the device designated as COM1.

 This debugging arrangement works great with CodeView under MS-DOS, but
 it becomes unworkable with CVP under OS/2 because the internal calls
 that are used to set up the redirection do not account for time-outs
 due to inactivity. Thus, if you are entering commands from the remote
 terminal at a steady pace, everything proceeds smoothly. However, if you
 stop and wait for more than about 60 seconds without doing any input,
 the port will time-out and leave you stranded because the keyboard no
 longer responds.

 In a normal debugging session, it is quite likely that there would be
 many instances greater than 60 seconds where input is not yet needed
 or desired; therefore, this situation quickly becomes intolerable. The
 only way to regain control is to enter CTRL+C at the PC keyboard,
 which ends the redirection. At that point, you could enter "=COM1"
 again on the PC keyboard to restart the redirection if you so desired.


 23. CVP 2.30 Does Not Allow Pathnames for DLLs Specified with /L

 Product Version(s): 2.30
 Operating System:   OS/2
 Flags: ENDUSER | buglist2.30
 Last Modified: 10-OCT-1989    ArticleIdent: Q49377

 Protected-mode CodeView (CVP) Version 2.30 allows debugging of dynamic
 link libraries (DLLs) by specifying their names on the command line
 with the /L switch. Because of a problem exclusive to CVP 2.30, this
 particular version of the debugger does not allow a pathname to be
 used with /L to specify the DLL's location in another directory.
 Therefore, all DLLs to be debugged with CVP 2.30 must reside in the
 current working directory.

 Since DLLs are also required to be in a directory that is on the
 LIBPATH, two copies of the DLL may need to be resident on the disk,
 unless the current working directory is also a LIBPATH directory.

 Microsoft has confirmed this to be a problem with CodeView Version
 2.30. We are researching this problem and will post new information as
 it becomes available.

 When tracing a program under CodeView that calls DLLs, the only way to
 trace into the code of a particular DLL is if the DLL was specified
 ahead of time on the command line with /L when CVP was invoked. If a
 program statement is traced that calls a DLL that was not specified by
 /L, then CodeView executes all the code in the DLL and returns control
 back at the line following the call to the DLL. Thus, the call is
 handled as if the step command, rather than the trace command, had
 been used.

 You can indicate only one DLL with the /L switch, so debugging
 multiple DLLs requires multiple /L switches. Normally, the switch is
 followed by a space and the name of the DLL to be debugged, and if the
 DLL is not located in the current directory, a path may precede the
 DLL name. It is only with CVP 2.30 that this becomes a problem because
 a pathname is not recognized with this version, so tracing into the
 DLL is prevented.

 Unfortunately, CodeView does not display error messages for improper
 use of the /L switch, so if the DLL is not found, there is no message
 indicating this. Instead, CodeView does not allow debugging of the
 improperly specified DLL. Use of a pathname with /L with CVP 2.30
 causes this same behavior.

 The only workaround for DLL debugging with CVP 2.30 is to keep a copy
 of the DLL in the current working directory from which CodeView is
 invoked. Thus, if the current directory is not a directory specified
 on the LIBPATH, there must be two copies of the DLL on the disk. It is
 very important that the two copies are exactly the same because
 differing code makes any attempts at debugging very difficult and
 confusing.

 A common practice is to put a period (.) as the first directory on
 the LIBPATH because this makes the current working directory a LIBPATH
 directory, eliminating the need for two copies of the DLL. More
 information on this practice can be found by querying on the
 following words:

    CodeView DLL debugging and libpath


 24. Label Finding Command Does Whole Word Search, Not Text Search

 Product Version(s): 2.20 2.30 | 2.20 2.30
 Operating System:   MS-DOS    | OS/2
 Flags: ENDUSER |
 Last Modified: 27-OCT-1989    ArticleIdent: Q49378

 In CodeView Versions 2.20 and 2.30, under the Search menu is the Label
 option for searching for a label. Unlike the Find option, which
 searches the source code for any regular expression, the Label option
 searches the executable code for an assembly language label.

 This search is not a text search and does not accept regular
 expressions. The only way to find a label is to specify the entire
 label name as the search string. In addition, if the Case Sense option
 is selected on the Options menu, the label is found only if the case
 of each character matches exactly.

 For example, if you want to find the code for the standard C
 stack-checking function "_chkstk", choose Search Label, and type in
 "__chkstk" (without the quotation marks), and press ENTER. This
 switches you into assembly mode, if you weren't there already, and
 puts the line with the __chkstk label at the top of the window. The
 two underscores are required since C appends an underscore to the
 front of all labels and the original function name is "_chkstk".

 You will receive the error message "Unknown Symbol" if the label
 cannot be found or if you mistype or incompletely type the correct
 name. For example, "_chkstk", "chkstk", "__chk", and "__chkstks" all
 fail to find a match in the above example. If Case Sense is on,
 searching for the label "__CHKSTK" also results in failure.


 25. The Assemble Command with ADD Instructions

 Product Version(s): 2.20 2.30  | 2.20 2.30
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | buglist2.20 buglist2.30
 Last Modified:  9-AUG-1989    ArticleIdent: Q40225

 Problem:

 In CodeView, I'm using the assemble command to change my ADD
 instruction, and it changes all the code from that point on.

 Response:

 If you had the instruction ADD AL,44, for example, and you wanted to
 change the 44 to 45 (or any other number), you could use the Assemble
 command to do it. The Microsoft Macro Assembler generates a 04 44 for
 that instruction; however, when changing the 44 to 45, CodeView
 generates an 80 C0 45, which is still the correct instruction of ADD
 AL,45. However, it's a 3-byte instruction. Inserting one extra byte
 into your code will cause each op code from that point on to be off by
 one.

 Microsoft has confirmed this to be a problem in Versions 2.20
 and 2.30 of CodeView. We are researching this problem and will
 post new information as it becomes available.



 26. CV Prior to 3.00 Needs /S for Mouse to Appear in OS/2 DOS Box

 Product Version(s): 1.00 1.10 1.11 2.00 2.10 2.20 2.30 2.35
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified:  6-FEB-1991    ArticleIdent: Q23646

 With all versions of real-mode CodeView (CV) earlier than version
 3.00, the mouse cursor does not display when running in a DOS session
 under OS/2 in the DOS compatibility box.

 The situation exists because the mouse draws the pointer only in video
 page zero, while CodeView uses video page one. This problem is caused
 by OS/2 itself because the mouse cursor works normally under DOS.

 To work around this limitation with CV 1.x or 2.x, invoke CodeView
 with the /S switch so screen swapping is used as the method of screen
 exchange. This method forces CodeView to swap in and out of page zero.

 Beginning with version 3.00, CodeView detects whether it is running in
 a DOS session under OS/2, and if so, automatically starts up with /S
 as the default in order to make the mouse visible.


 27. CVPACK /p Causes a More Complete Packing

 Product Version(s): 2.20
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 28-MAR-1989    ArticleIdent: Q38020

 When you are unable to load your program into CodeView, try packing
 the program with CVPACK.EXE. If you want a more complete packing of
 your executable, then run CVPACK.EXE with the /p option. This option
 will take longer to run, but it will generate better results.

 The /p option for CVPACK.EXE is documented on Page update-17 in the
 "Microsoft C 5.1 Optimizing Compiler, CodeView and Utilities,
 Microsoft Editor Mixed-Language Programmer's Guide."

 Normally, CVPACK discards unused debugging information and appends
 it to the file. With the /p option, CVPACK discards the unused
 debugging information, then proceeds to sort it throughout the
 executable file.


 28. Mouse Cursor Disappears After Right Click

 Product Version(s): 2.20 2.30 | 2.20 2.30
 Operating System:   MS-DOS    | OS/2
 Flags: ENDUSER |
 Last Modified: 14-AUG-1989    ArticleIdent: Q38021

 Problem:

 I have just clicked my right mouse button to acknowledge a pop-up
 message and my mouse cursor has disappeared. I had just clicked my
 right mouse button before for another operation.

 Note: This also occurs when you hit any button on the three button
 Logitech mouse.

 Response:

 To get your mouse cursor back again, redraw the screen with the "@"
 command.


 29. CVP 2.30 Hangs When /O Is Specified, but Child Is Not Debugged

 Product Version(s): 2.30
 Operating System:   OS/2
 Flags: ENDUSER | buglist2.30
 Last Modified: 27-OCT-1989    ArticleIdent: Q49381

 Beginning with protected-mode CodeView (CVP) Version 2.30, you can
 debug child processes from within a parent process's CodeView session
 by invoking CodeView with the /O switch. When the program is executed
 to the point where the child process is invoked, CodeView displays a
 prompt showing you the child's process ID (PID) and asks, "Do you wish
 to debug (y/n)?". Entering "y" brings up the child process and allows
 you to debug it. Pressing "n" should cause the child to execute
 without any debugging.

 Unfortunately, there is a problem in CVP 2.30 that causes CodeView to
 hang if you answer no to debugging the child. The only workaround is
 to always answer yes when prompted to debug a child process, or to
 invoke CodeView without the /O switch because this prevents the prompt
 entirely.

 Microsoft has confirmed this to be a problem with CodeView Version
 2.30. We are researching this problem and will post new information as
 it becomes available.

 If the program you are debugging is not a Presentation Manager (PM)
 application, you may be able to kill the CodeView session if it should
 hang as a result of answering "n" to the debugging child process. You
 must switch to the Task Manager and use it to close the hung CodeView
 session. If you are working on a PM application, the only workaround
 may be to reboot the computer.


 30. Cannot Debug Code in Overlays in Small or Compact Model

 Product Version(s): 2.10 2.20 2.30
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 14-AUG-1989    ArticleIdent: Q27128

 Question:

 I have a C program, compiled with Microsoft C Version 5.00, which
 consists of several modules linked together as overlays. I am not able
 to trace into code in the overlays. I compiled in the default memory
 model. What is wrong?

 Response:

 The modules must be compiled in medium or large memory model to be
 overlaid. In the default model (small), or in the compact model, there
 is only one code segment, which cannot be overlaid. The main module is
 always resident and cannot be overlaid. You must use the compile
 option /AH, /AL, or /AM.


 31. Code that Will Hang IBM XTs or Compatibles

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | TAR57675 buglist1.00
 Last Modified:  8-NOV-1988    ArticleIdent: Q23856

 Problem:

 The following code will hang IBM XTs or compatibles if specific
 commands are issued when inside of CodeView:

    #include <stdio.h>
    main()
    {
         int n;
         double f;

         while(1)   {
                    scanf("%d",&n);
                f=1.0;
                while (n>1) f=f*n--;
                   printf("%.101g%c",f,'\n');
                    }
    }

 For the program to fail in CodeView, first set a breakpoint at
 instruction f=1.0. Issue the Go command, then the P command.

 Response:

 This is corrected in CodeView version 2.20.

 A workaround is to place a breakpoint at the instruction before or
 after the assignment to f.


 32. /DOSSEG Link Switch Fails to Make CodeView .exe

 Product Version(s): 2.20 2.30
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified:  9-AUG-1989    ArticleIdent: Q38163

 Question:

 CodeView is failing on an .exe produced using the /DOSSEG linker
 switch. CodeView responded to an attempt to run with this .exe
 with a "not enough space" diagnostic. What is the problem?

 Response:

 The modules below demonstrate the problem. In this case, compiling the
 C source module and assembling the MASM source module with the
 appropriate CodeView switches, then linking with the /CO /DO switches
 generates a bad .exe. The problem is that CodeView displays source
 with extended ASCII characters.

 To work around this problem, put .DOSSEG in the MASM modules
 being linked, and omit the /DO switch rather that trying to
 force the linker to do the work. Also, switching the order of
 the linker switches may solve the problem.

 The following example demonstrates the problem:

 #include <stdio.h>
 main ()
   {
   long int getds(void), getdsq(void);
   printf("ds.DATA  = %lX\nds.DATA? = %lX\n",getds(),getdsq());
   }

 **************************************************************
 ;        DOSSEG could be put here
         .MODEL  small
         .DATA
 array   dd      0
         .DATA?
 arrayq  dd      ?
         .CODE
         PUBLIC  _getds,_getdsq
 _getds  PROC
         mov     ax,SEG array
         mov     dx,ds
         ret
 _getds  ENDP
 _getdsq PROC
         mov     ax,SEG arrayq
         mov     dx,ds
         ret
 _getdsq ENDP
         END


 33. 3270 ERMA Emulator

 Product Version(s): 1.00 1.10 2.00 2.10 2.20 2.30
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified:  9-AUG-1989    ArticleIdent: Q24200

 Question:
    Does CodeView support the 3270 ERMA emulator?

 Response:
    CodeView does not directly support any other program. In this case,
 the 3270 ERMA emulator would have to accommodate CodeView. CodeView
 performs some hardware specific routines (e.g. checking to see if an
 EGA is present) and makes some assumptions on the state of the
 machine. If another program changes the state of the machine, it may
 not work with CodeView. It has been reported that CodeView will hang
 if the 3270 ERMA emulator is enabled; we recommend you disable the
 emulator before running CodeView.


 34. Flipping and Swapping Screens

 Product Version(s): 1.00 1.10 2.00 2.10 2.20 2.30
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified:  9-AUG-1989    ArticleIdent: Q24201

 Question:
    What is the difference between flipping and swapping in CodeView?

 Response:
    Both are ways of maintaining two alternate screens for display on
 one monitor. The difference is in the way the task is accomplished.
    When swapping is selected, CodeView allocates a 16K buffer (a 4K
 buffer for a monochrome adapter) to hold the alternate screen. When
 the other screen is required, CodeView swaps the screen into the
 display buffer and places the other screen into the storage buffer.
 Swapping takes memory and time, but it does not have the limitations
 of flipping.
    Flipping uses the video-display pages of the graphics adapter to
 store each screen of text. When the alternate screen is required, the
 other page is selected. Flipping is much faster than swapping and does
 not require the 16K buffer. However, it cannot be used with a
 monochrome adapter, or with programs that display graphics or use the
 video pages.


 35. CODEVIEW.DOC Incorrectly States /E Uses Extended Memory

 Product Version(s): 2.20
 Operating System:   MS-DOS
 Flags: ENDUSER | docerr
 Last Modified: 10-NOV-1988    ArticleIdent: Q27763

 The CODEVIEW.DOC file included in Microsoft C Version 5.10 states that
 the /E switch enables use of extended memory for CodeView's symbol
 table.

 This is a documentation error in the CODEVIEW.DOC file. CodeView uses
 expanded, not extended memory.


 36. WINDOWCOMPAT Directs CodeView to Create a Window

 Product Version(s): 2.20 2.30
 Operating System:   OS/2
 Flags: ENDUSER | S_C
 Last Modified: 10-NOV-1989    ArticleIdent: Q49423

 The WINDOWCOMPAT directive in a linker definition file can cause
 strange behavior in non-Presentation Manager (PM) programs being
 debugged under CodeView. WINDOWCOMPAT is one of three application
 types that can be specified after the NAME directive. WINDOWCOMPAT is
 used for OS/2 programs that use VIO, MOU, and KBD calls and can be
 used inside a PM window or as a separate screen group.

 Debugging a non-PM application that was linked with the WINDOWCOMPAT
 option instructs CodeView to create a PM window to run the program. In
 some cases this feature could be desirable, but for most debugging, a
 PM window is only cumbersome. The way to work around this feature is
 to relink without the WINDOWCOMPAT directive.


 37. The CodeView Port Input Command Example Is Unclear

 Product Version(s): 2.20 2.30 | 2.20 2.30
 Operating System:   MS-DOS    | OS/2
 Flags: ENDUSER | H_MASM H_FORTRAN S_Pascal
 Last Modified: 27-OCT-1989    ArticleIdent: Q49537

 The CodeView example for port input command is unclear in the
 following manuals:

 1. Page 150 of Microsoft C 5.10 "CodeView And Utilities, Microsoft
    Editor, Mixed Language Programming Guide"

 2. Page 150 of Microsoft Macro Assembler 5.10 CodeView and Utilities

 3. Page 150 of Microsoft Pascal 4.00 CodeView and Utilities

 4. Page 127 of Microsoft FORTRAN 5.10 CodeView and Utilities

 The example assumes the radix is in hexadecimal. To set the radix to
 hexadecimal, type in the following command:

    >n16

 After setting the radix to hexadecimal, the example works properly.

 If the radix is not in hexadecimal, a "0x" must be present for
 CodeView to recognize the value as a hex format. The following example
 shows how to use the port input command if CodeView is not in
 hexadecimal radix:

    >I 0x2f8


 38. The Difference Among Watch, Watchpoint, and Tracepoint

 Product Version(s): 1.00 1.10 2.00 2.10 2.20 2.30 | 2.20 2.30
 Operating System:   MS-DOS                        | OS/2
 Flags: ENDUSER |
 Last Modified: 14-AUG-1989    ArticleIdent: Q24225

 Question:

 What is the difference between a watch, a watchpoint, and a
 tracepoint?

 Response:

 A "watch" command will monitor an expression or a range of memory
 addresses, and update the watch window each time the expression or any
 location in the range changes. Using a watch never will cause program
 execution to stop; it simply "watches" unconditionally.

 A "watchpoint" monitors an expression (and an expression only) during
 program execution. It will update its value in the watch window
 whenever it changes. However, when the watchpoint expression becomes
 true (nonzero), program execution is stopped.

 A "tracepoint" monitors an expression or a range of memory addresses
 and displays the expression or the range being monitored in the watch
 window. It will stop program execution when the expression or any
 location in the range changes. Please note that writing over the old
 value at a memory location with the same value is not considered a
 change.

 The following example summarizes this information:

 Command     Object To Watch          Conditionally    Condition To
                                      Stops            Stop On
 -------     ---------------          -------------    ------------

 WATCH       expression or            No               (none)
             range of memory

 WATCHPOINT  expression               Yes             expression becomes
                                                      true (nonzero)

 TRACEPOINT  expression or            Yes             expression or
             range of memory                          in range changes
                                                      location

 Note: the "monitoring" described above is done in only window mode. If
 sequential mode is being used, you must use the Watch List command to
 see the values of any of the three types of watch statements.


 39. Tracking Down a Null Pointer Assignment Error

 Product Version(s): 1.00 1.10 2.00 2.10 2.20 2.30 | 2.20 2.30
 Operating System:   MS-DOS                        | OS/2
 Flags: ENDUSER | S_C
 Last Modified: 21-AUG-1989    ArticleIdent: Q24270

 Question:

 I consistently get the error number R6001 "null pointer assignment"
 when I run my program. How can I use CodeView to determine the point
 at which the null pointer assignment is occurring?

 Response:

 Use a tracepoint, which can be set to watch a range of memory up to
 128 bytes. It will halt the execution of the program when any value in
 this range is changed. If you set a tracepoint over the entire range
 of the null segment, the program will halt immediately after the
 instruction that wrote over the null segment.

 The location of the null segment is available in the link maps of
 Microsoft compilers. It starts at DS:0 and is 42H bytes long. The
 Microsoft copyright notice is written there at program startup and
 if this area is written to during the course of the program, the
 error r6001 is generated. The most common cause of this error is
 using a pointer that has not been initialized to point to a memory
 area. Pointers that have not had space allocated for them (using
 malloc for example) or that have not been assigned to a specific
 data element (arrays or structures for example) are considered
 uninitialized.

 An example of using CodeView to determine where an unitialized pointer
 is being used follows:

 g main                  /* go to the beginning of main() */
 n16                     /* switch to hexadecimal (base 16) */
 tpb DS:0 DS:42          /* set a Trace Point of type Byte starting
                               at address DS:0 and extending to DS:42 */

 When any value in the specified range changes, CodeView will stop the
 execution of your program. The previously executed line was probably
 the line that caused the R6001 error.


 40. How to Successfully Debug VioPopUp() Code with CodeView

 Product Version(s): 2.20 2.30 2.35
 Operating System:   OS/2
 Flags: ENDUSER |
 Last Modified: 27-FEB-1990    ArticleIdent: Q58647

 Debugging programs that take advantage of OS/2's VioPopUp() call can
 present a potentially dangerous situation. Due to the nature of the
 VioPopUp() call, any attempts to trace into the VioPopUp call will cause
 your machine to hang. The workaround for this difficulty is to set a
 breakpoint outside of the VioPopUp() call [after the VioEndPopUp()], and
 then press F5 to instruct CodeView to execute to the next breakpoint.

 The VioPopUp() call brings forward a temporary pop-up text screen group
 that can be used to display text information without altering the
 context of the foreground screen. When a VioPopUp() call is executed, the
 current foreground screen group loses the keyboard focus to the pop-up
 screen. Therefore, when you trace into a VioPopUp() call, the pop-up
 text comes forward and CodeView, running in the foreground, loses the
 keyboard focus and cannot execute a trace instruction. At this time,
 CTRL+ESC or ALT+ESC will not change the deadlock situation and the
 only alternative is to reboot.

 To work around this problem, it is essential that you do NOT step into
 a VioPopUp call. Instead, press F5 to execute to the next breakpoint.
 Setting the breakpoint AFTER the VioEndPopUp() call is critical.


 41. Capabilities of Real Mode CodeView and the 386

 Product Version(s): 2.00
 Operating System:   MS-DOS
 Flags: ENDUSER | s_c, h_masm, h_fortran, s_pascal
 Last Modified:  1-DEC-1988    ArticleIdent: Q38205

 The information below discusses the CodeView debugger and its use
 of 80386 hardware capabilities.

 The DOS CodeView does not keep track of any of this information because
 DOS does not use any of these features. Essentially, a 386 running DOS
 is just a very fast PC and CodeView treats it as such.

 The OS/2 CodeView does not have the privilege to track many of the
 OS/2 functionality.

 The following is a list of CodeView behaviors:

 1. CodeView does not keep track of task states.

 2. CodeView does not handle privilege levels.

 3. CodeView Version 2.20 makes limited use of the 386 debug
    registers. Previous versions do not use these registers.

 4. CodeView does not keep track of interrupt gates and trap gates.

 5. CodeView cannot operate in both real and Virtual 86 mode.

 6. CodeView cannot trace to protected mode and back to real mode.

 7. CodeView does not handle traces in protected mode.


 42. Flip/Swap Setting Crucial to Debugging PM Apps with Children

 Product Version(s): 2.30
 Operating System:   OS/2
 Flags: ENDUSER |
 Last Modified: 10-NOV-1989    ArticleIdent: Q50514

 Using protected mode CodeView (CVP) to debug Presentation Manager (PM)
 programs that spawn one or more child processes can be rather
 difficult. CVP works correctly for debugging just the parent PM
 process, but once you begin CodeView with the /O option to specify
 that you also want to debug child processes, you may find that you
 hang the computer quite regularly during your debugging session.

 CodeView itself does not have a problem with PM programs even if they
 do invoke child processes. It is only when you use the /O switch to
 debug the children at the same time that you run into difficulty. This
 is because of problems with CodeView conflicting with the OS/2 kernel
 as you bring a process to the foreground for debugging, while a
 system-dependent process like the PM parent is relegated to the
 background where it can become blocked.

 For example, if the parent gets to a point where it is waiting on a
 message, but it is not in the foreground, there is no way to get the
 focus back to this waiting process and you are essentially hung. The
 parent cannot process the message because it must be in the foreground
 to do so, and CodeView cannot continue until the message is processed,
 so it just waits.

 The key to debugging the parent and child processes of a PM program at
 the same time is the setting of Flip/Swap on the Options menu. Under
 CodeView, Flip/Swap ON forces messaging, Flip/Swap OFF does not.
 Therefore, you must turn Flip/Swap on and off as you go, depending on
 which particular part of the program you are currently debugging. The
 Flip/Swap setting is crucial in determining whether you hang the
 system or not.

 The ability to debug child processes from the parent's CodeView
 session became an available option beginning with CVP Version 2.30. By
 specifying the /O switch on the command line, CVP allows you to trace
 into child processes. (See the CVP 2.30 Note below if you are using
 that particular version of CodeView.)

 As far as actually debugging child processes in PM programs, you must
 proceed in an exacting manner. Unfortunately, the specifics are
 different for every program, so an all-encompassing set of debugging
 procedures cannot be devised. Nevertheless, the following general
 guidelines can be used for debugging most PM applications with their
 accompanying child processes:

  1. It is only with the /O option that any of this becomes critical.

  2. You need to debug in a full screen and not a PM window.

  3. Remember, Flip/Swap ON forces messaging, Flip/Swap OFF does not.
     Therefore, while you begin debugging in the parent program, you
     should have Flip/Swap ON, since you need messaging whenever you
     are doing any of the window initialization routines.

  4. Set a breakpoint in the parent somewhere after the window
     initialization code, but before the call to start the child
     process. It varies, but it usually works to put the breakpoint at
     the "while get message - dispatch message" loop or in the
     ClientWndProc procedure at the main switch statement.

  5. You must make sure that the breakpoint is placed in a position
     where you will stop at it before the prompt appears to ask you if
     you want to debug the child, but after ALL the window
     initialization has been completed. You will also probably need to
     set another breakpoint at the point where the parent program is
     going to begin executing again after you have finished working
     with the child.

  6. Do a GO, and when the breakpoint is reached, turn Flip/Swap OFF.
     Make sure that the prompt to debug the child is not already
     visible or you will lock up.

  7. Do a GO (or some traces) and you should get the prompt to debug
     the child. Answer "Y" and you should be able to debug the child
     process at this point.

  8. Use the Process command (the "|") to gain access to the child.
     Never use CTRL+ESC or ALT+ESC to switch to the other processes
     because these will almost assuredly cause you to hang.

  9. Go ahead and set breakpoints, watches, etc. in the child and do
     your debugging.

 10. After the child process is completed, use the Quit command to exit
     the child process's CodeView screen or use the Process command to
     reselect the parent process.

 11. Once you have returned to the parent process, and before you do a
     Restart (or load), or before you do ANY other window
     initialization, you MUST turn Flip/Swap ON again.

 12. Remember to always be aware of where you are in the program and
     what the current state of Flip/Swap is, since turning Flip/Swap on
     or off at the wrong time will almost always cause you to hang.

 Again, this is only the general outline of steps to follow and each
 application requires different specific steps. Don't be too surprised
 if you still run into occasional lock-ups.

 CVP 2.30 Note: When using the /O switch with CVP Version 2.30, there
 is a bug that may also cause you to hang. The problem involves using
 /O on the command line and then saying "No" when asked if you want to
 debug the child. So, with this version of CodeView, you should always
 answer "Yes" when asked if you wish to debug the child.

 For more information on this problem, use the following query:

    CodeView 2.30 hangs debugging child processes


 43. Can't Debug .COM Files in Source Mode

 Product Version(s): 2.00 2.10 2.20 2.30
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified:  9-AUG-1989    ArticleIdent: Q38288

 The .COM format files created with the Microsoft Macro Assembler
 cannot contain symbolic and source-line information for the CodeView
 debugger. You can only debug these files in assembly mode.


 44. CODEVIEW.DOC File Error: Mouse Works with the /2 Option

 Product Version(s): 2.20
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified:  8-NOV-1988    ArticleIdent: Q27764

 Question:
    The CODEVIEW.DOC file included with Microsoft C Version 5.10 states
 that using the /2 switch disables mouse support on the debugging
 display. Is this true?

 Response:
    This is an error in the CODEVIEW.DOC file.
    CodeView does support the mouse when using the /2 switch. In fact,
 if you are debugging a program which itself uses the mouse, using the
 /2 switch will allow you to use the mouse on CodeView's debugging
 screen as well as your application's output screen.


 45. "?CANNOT DISPLAY" After Column 135 in Command Window

 Product Version(s): 3.00 3.11 | 3.00 3.11 3.50
 Operating System:   MS-DOS    | OS/2
 Flags: ENDUSER |
 Last Modified:  6-FEB-1991    ArticleIdent: Q68696

 The code below demonstrates a limitation of the CodeView debugger.
 When the command "?y" is executed in the COMMAND window, the structure
 "y" is displayed. However, CodeView displays the structure only to
 column 135 and then prints "?CANNOT DISPLAY," ignoring the rest of the
 elements in the structure. The output appears as follows:

    --------------------------command----------------------------
   |>?y                                                          |
   |{this_field_01=0x0000, ... ,this_field_07=?CANNOT DISPLAY    |
   |                        ^                 ^                  |
   |                        |                 |                  |
   |                  Fields 2-6 displayed    Column 135         |
   |                                                             |
    -------------------------------------------------------------

                       CodeView Command Window

 To view all elements of a structure, you should use the QUICK WATCH
 function. In the example below, the contents of the whole structure
 can be seen by typing "??y". A dialog box will appear on the screen
 showing the contents of the structure. By scrolling down in the dialog
 box, the contents of every element of the structure can be seen. The
 structure contents are displayed as follows:

           --------------- Quick Watch -----------------
          |                                             |
          |-y                                           |
          |   this_field_01=0                           |
          |   this_field_02=0                           |
          |   this_field_03=0                           |
          |   this_field_04=0                           |
          |   this_field_05=0                           |
          |   this_field_06=0                           |
          |   this_field_07=0                           |
          |   this_field_08=0                           |
          |   this_field_09=0                           |
          |   this_field_10=0                           |
          |   this_field_11=0                           |
          |   this_field_12=0                           |
          |   this_field_13=0                           |
          |   this_field_14=0                           |
          |   this_field_15=0                           |
           ---------------------------------------------

                       Quick Watch of Variable

 Sample Code
 -----------

 struct x {
    int this_field_01;
    int this_field_02;
    int this_field_03;
    int this_field_04;
    int this_field_05;
    int this_field_06;
    int this_field_07;
    int this_field_08;
    int this_field_09;
    int this_field_10;
    int this_field_11;
    int this_field_12;
    int this_field_14;
    int this_field_15;
    int this_field_16;
    int this_field_17;
    int this_field_18;
    int this_field_19;
    int this_field_20;
 };

 main()
 {
     struct x y;
 }


 46. Debugging PM Apps with Two Monitors Does Not Require /2 Switch

 Product Version(s): 2.20 2.30
 Operating System:   OS/2
 Flags: ENDUSER |
 Last Modified: 17-JUL-1990    ArticleIdent: Q49824

 Problem:

 I am using CodeView to debug my Presentation Manager (PM) program and
 I am using the /2 switch to redirect the CodeView screen to a
 monochrome monitor. When I press F5 to start my program, a protection
 violation occurs, but it works correctly when I run it from the OS/2
 command line.

 Response:

 The /2 switch for CodeView is not supported for Presentation Manager
 application debugging. However, you may redirect the CodeView screen to
 a monochrome monitor if you do the following:

 1. Start a full-screen command prompt.

 2. At the prompt, type the following command (this puts the prompt on
    the monochrome monitor):

       mode mono

    Note: You must be in a 25-line screen mode before you attempt the
    mode mono. If you are in a 43- or 50-line mode, the display is
    corrupted.

 3. At the prompt, type the following command, where "appname" is your
    application's name:

       cvp appname

 4. After you are finished debugging, you can return the prompt to your
    primary display by typing the following command:

       mode co80


 47. How CodeView Interprets Values (octal, decimal, hexadecimal)

 Product Version(s): 1.x 2.00 2.10 2.20 | 2.20
 Operating System:   MS-DOS             | OS/2
 Flags: ENDUSER |
 Last Modified: 23-NOV-1988    ArticleIdent: Q38299

 Problem:

 When trying to watch a portion of memory, I have a problem with
 the following command at the dialog prompt:

    WW DS:0050 L 4.

 I thought this should have created a watch on the four words starting
 at offset 0x50. It actually set the watch starting at 0x28, CodeView
 interpreted the number as if it had been in base 8. Using the N
 command to change the radix doesn't make any difference.

 Response:

 In this case, the 0's before the offset cause CodeView to evaluate the
 expression in octal. CodeView provides three different prefixes for
 numbers to use an explicit base: 0 signifies octal, 0n signifies
 decimal, and 0x signifies hexadecimal. The current radix setting will
 have no bearing on numbers entered with these prefixes; however, it
 will affect those without prefixes.

 The lines below have different meanings when setting watches.
 The left column is the command, while the right column is an example
 of the display produced in the watch window. Radix is assumed to be 10.

 The following is an example:

 1. ww 50               50    :  0067:0032  6942

 2. ww 050              050   :  0067:0028  6328

 3. ww 0n50             0n50  :  0067:0032  6942

 4. ww 0x50             0x50  :  0067:0050  6163

 The first command sets the watch at the address specified using the
 current radix. This address will change when you use the N command to
 change the radix; the 50 on the left of the watch remains the same;
 however, the offset in the address will change to watch 50 in the new
 base. This address will always be displayed in hexadecimal, but 50
 will be evaluated differently.

 Examples 2 through 4 show watches being set in octal, decimal, and
 hexadecimal modes, respectively. These addresses will never change
 with a change of radix.

 Notice that watches 1 and 3 match. This is because by default CodeView
 is in base 10, so 50 and 0n50 evaluate to the same thing. Using N 8 will
 cause watches 1 and 2 to match, and N 16 will match 1 and 4.


 48. Interrupt Conflict with Greenleaf Libraries

 Product Version(s): 2.20    | 2.20
 Operating System:   MS-DOS  | OS/2
 Flags: ENDUSER | CV CVP
 Last Modified: 23-NOV-1988    ArticleIdent: Q38314

 The Greenleaf Comm Library, a collection of asynchronous
 communications functions for use with the C compiler, causes severe
 complications with CodeView (e.g. crashes, lockups) due to interrupt
 conflicts. Greenleaf Software is aware of this difficulty and will
 advise customers of the incompatibility.

 No workarounds are available. Greenleaf Software is located in
 Carrollton, TX, and can be reached at (214) 248-2561.


 49. CodeView Gives "Illegal Instruction" on Clone 386

 Product Version(s): 2.20
 Operating System:   MS-DOS
 Flags: ENDUSER | CV
 Last Modified: 23-NOV-1988    ArticleIdent: Q38317

 Some clones that are not entirely IBM-compatible under CodeView may
 give an "illegal instruction" message upon executing Go (F5), and then
 hang, requiring a warm boot. If the instruction being called illegal
 is FINIT or FNINIT, the particular ROM BIOS probably has a built-in
 387 emulator. Either turn off the emulator, or set the environment
 variable SET NO87=(some string).



 50. Thirty-Two-Bit Register Not Visible under OS/2

 Product Version(s): 2.20
 Operating System:   OS/2
 Flags: ENDUSER |
 Last Modified: 23-NOV-1988    ArticleIdent: Q38375

 Thirty-two-bit registers are not viewable (using F2) under CVP even if
 you have an 80386-based machine. This is not a problem with CodeView;
 it is a limitation.

 Real mode CodeView (CV) DOES support viewing 32-bit registers. This
 is because of the unprotected and generally more flexible nature of
 DOS. Using the full 32-bits of the 80386 under OS/2 is considered
 hazard-prone and is not supported by CVP.



 51. CodeView Instruction Pointer Miscounts Very Long Lines

 Product Version(s): 2.20
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist2.20
 Last Modified:  1-DEC-1988    ArticleIdent: Q38382

 CodeView may display the "current instruction" highlight on the wrong
 line if the source file contains lines that are very long.

 The compiler counts the long lines as one line, but CodeView counts
 the very long lines as two lines. This makes the line number
 calculations incorrect and causes the "current line" highlight to
 appear on the wrong line. This problem does not occur if the source
 lines are less than 251 characters in length.

 Because the Microsoft Editor breaks lines that are longer than 250
 characters, this problem does not occur if you create and maintain
 your source files with the Microsoft Editor.

 Microsoft has confirmed this to be a problem in CodeView Version 2.20.
 We are researching this problem and will post new information as it
 becomes available.


 52. CodeView Requires PUBLIC to Trace MASM Program in Source Mode

 Product Version(s): 2.20
 Operating System:   MS-DOS
 Flags: ENDUSER | H_MASM
 Last Modified:  3-MAY-1989    ArticleIdent: Q44006

 A MASM program that runs perfectly from a DOS prompt refuses to trace
 in source mode inside of CodeView. The program single-steps in
 assembly mode, but an attempt to trace into the code in source mode
 results in the program terminating upon reaching the first data
 declaration.

 In addition, the program does not come up in source mode when CodeView
 is started, but can be changed into source mode with "View" "Source".

 This problem happens when the code and data segments are not declared
 as "PUBLIC". The code is valid and executes perfectly inside of
 CodeView or from a DOS prompt. However, CodeView cannot follow the
 logic at a source level.

 A program constructed in the following manner exhibits the symptoms
 described above:

 TITLE    myprog

 StackSeg Segment STACK
 .
 .
 .
 DataSeg  Segment DATA
 .
 .
 .
 CodeSeg  Segment CODE
 .
 .
 .
 END      myprog

 However, if the following minor changes are made to the program, and
 the segments are declared as "PUBLIC", CodeView can trace through the
 program in source mode:

 TITLE    myprog

 StackSeg Segment STACK
 .
 .
 .
 DataSeg  Segment WORD PUBLIC 'DATA'
 .
 .
 .
 CodeSeg  Segment WORD PUBLIC 'CODE'
 .
 .
 .
 END      myprog


 53. Cannot Use /2 Switch on IBM PS/2 in CodeView

 Product Version(s): 2.10 2.20  2.30 | 2.20 2.30
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | SR# G881031-5515
 Last Modified:  9-AUG-1989    ArticleIdent: Q38865

 To use the /2 switch with CodeView, your computer must be equipped
 with a monochrome display (MDA) and a color display (CGA/EGA/VGA). The
 IBM PS/2 computers aren't currently configurable this way because they
 come with built-in VGAs or MDAs, but not both.

 If a hardware vendor starts selling MDAs that can be added to systems
 with built-in VGAs, this problem will be solved. An MDA card is
 needed that plugs into the PS/2 and works correctly in conjunction
 with the built-in VGA so that PS/2 owners can have a dual-monitor
 system.

 Currently, there is no solution to this debugging restriction other
 than using CodeView through the com port in sequential mode (/T) with
 a debugging terminal.


 54. CodeView Does Not Support Debugging Spawned Process

 Product Version(s): 2.20 2.30
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 26-FEB-1990    ArticleIdent: Q58653

 The following are several reasons why CodeView doesn't provide
 debugging support for spawned processes under DOS:

 1. DOS is not a multitasking operating system. CodeView cannot start
    another thread/process to watch the execution of the spawned
    process.

 2. DOS does not provide debugging support for the DOS BIOS calls (int
    21h). Since all spawn() and exec() functions under DOS have to go
    through the BIOS to run, CodeView cannot follow the spawned
    program.

 3. DOS only recognizes 640K of memory; therefore, there is
    insufficient memory to debug a large program, since both the parent
    and child processes have to reside in memory at the same time.


 55. Display Settings for Compaq Gas Plasma Screen

 Product Version(s): 1.00 2.10 2.20 | 2.20
 Operating System:   MS-DOS         | OS/2
 Flags: ENDUSER |
 Last Modified:  6-DEC-1988    ArticleIdent: Q38866

 The default monitor settings for CodeView do not work properly with
 the Compaq gas plasma display adapter. Invoking CodeView with the /b
 switch corrects the problem.


 56. CodeView: Watchpoints and Tracepoints with Enumerated Types

 Product Version(s): 2.20   | 2.20
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | s_c
 Last Modified: 28-MAR-1989    ArticleIdent: Q42601

 CodeView will not display the members of an enumerated type as they
 are declared in a C program. Only the integer representations of these
 types of variables can be shown. The following is an example:

 /*  Example enumerated type.
  */

 enum e_type
 {
     var1,
     var2,
     var3
 };

 enum e_type foo = var1;

 CodeView will not display "var1", "var2", or "var3" when watching a
 variable of type e_type, such as foo. CodeView will instead show the
 integer values of the variable: 0, 1, and 2, respectively. In order to
 watch the variable foo, you must explicitly display its value as an
 integer. The following command will add the proper watch:

     w? foo,d

 To set a watchpoint or a tracepoint on the same variable, further type
 casts must be made. These lines will produce watchpoints and
 tracepoints on foo, as follows:

     wp? *(int *)&foo == 1
     tp? *(int *)&foo

 Trying to set a watchpoint without the proper type cast will result in
 the following error:

     Operand types incorrect for this operation

 Setting a tracepoint on foo without this type cast will set the
 tracepoint but will only show "?CANNOT DISPLAY" in the watch window.
 Going through the right steps will display the current integer value
 of the variable, as it should.


 57. "?CANNOT DISPLAY" Error Not Documented in CodeView Documents

 Product Version(s): 2.00 2.10 2.20 2.30 | 2.20 2.30
 Operating System:   MS-DOS              | OS/2
 Flags: ENDUSER | TAR64267 docerr
 Last Modified: 21-AUG-1989    ArticleIdent: Q24877

 Problem:

 When trying to evaluate (?), a function that returns void, I get the
 error "?CANNOT DISPLAY". I cannot find this error message in the
 "Microsoft CodeView Utilities and Editor" manual.

 Response:

 This error message is not contained in the CodeView manual.

 The "?CANNOT DISPLAY" error message will be displayed in cases where
 the expression evaluator cannot return a value, such as a function
 returning void.


 58. Watch Bytes (wb) Command Can Be Used to Watch a Buffer in HEX

 Product Version(s): 2.20 2.30 | 2.20 2.30
 Operating System:   MS-DOS    | OS/2
 Flags: ENDUSER |
 Last Modified: 17-JUL-1990    ArticleIdent: Q50224

 Question:

 Is there a way to keep tabs on the contents of a buffer via a watch
 command? We want to observe the contents of a 20-character buffer in
 HEX. The buffer is not necessarily null terminated.

 Response:

 The way to watch a buffer in CodeView in hexadecimal with the Watch
 command is to use Watch Bytes (wb) as follows:

    >wb *buffer L 10  ; this will watch the first 10 bytes of
                        buffer in HEX

 For the given example, you should follow the previous command with the
 following:

    >wb *(buffer + 10) L 10  ; this will watch the next 10
                               bytes in HEX.

 Please note that both the length specifier as well as the number 10
 used to offset the pointer in the second command are taken in the
 current radix. The example above assumes a radix of 10. You can
 explicitly specify the base of the number in hex as follows:

    >wb *buffer L 0x0a
    >wb *(buffer + 0x0a) L 0x0a

 For more information on the wb command in CodeView, see the "Microsoft
 CodeView and Utilities, Microsoft Editor, Mixed-Language Programming
 Guide" manual.


 59. Specifying Both /T and /W Disables Mouse

 Product Version(s): 2.20    | 2.20
 Operating System:   MS-DOS  | OS/2
 Flags: ENDUSER |
 Last Modified:  6-DEC-1988    ArticleIdent: Q38867

 If you invoke CodeView with the following, the use of your mouse is
 disabled:

    CV /T /W program

 Don't specify the /T switch. Using /T with /W produces mutually
 exclusive modes of operation.


 60. Illegal Instruction in CodeView

 Product Version(s): 1.x 2.00 2.10 2.20 | 2.20
 Operating System:   MS-DOS             | OS/2
 Flags: ENDUSER | S_C h_fortran S_PASCAL
 Last Modified:  6-DEC-1988    ArticleIdent: Q38868

 Question:

 When I compile and link my C program and try to run it under CodeView,
 execution stops on the open curly brace of main. The view then goes to
 assembly, and the message "Illegal instruction" appears in the dialog
 window. Is there something wrong with the startup code?

 Response:

 This error can be produced when the main module of a program is
 compiled for one memory model and is then explicitly linked with a
 library for a different model. When the startup code is linked to the
 entry point of the program, different size instructions are used for
 the different memory models. If the program expects one size and the
 linker links in a different size, the startup instructions will be
 misinterpreted and result in this error.


 61. Entering Double Words at a Prompt Prevents Reloading Program

 Product Version(s): 2.20 2.30
 Operating System:   MS-DOS
 Flags: ENDUSER| | S_C S_PASCAL H_FORTRAN H_MASM buglist2.30
 Last Modified: 30-NOV-1989    ArticleIdent: Q50410

 When using the Enter Double word (ED) command within the CodeView
 symbolic debugger and allowing the debugger to prompt, you will
 prevent the debugger from reloading your executable (using the L
 command). This problem occurs only when you allow the debugger to
 prompt you for the double word and you enter a double word.

 This problem can manifest itself in several ways, depending on the
 version and on other unpredictable circumstances. Symptoms of the
 problem include the following:

 1. Giving the message "No such file/directory"

 2. Giving the message "Arg list too long"

 3. Generating an internal debugger error 7

 Valid workarounds consist of entering words (not double words) at the
 prompt, or entering double words on the command line (without being
 prompted).

 Microsoft has confirmed this to be a problem with CodeView Version
 2.30. We are researching this problem and will post new information
 here as it becomes available.


 62. CodeView 2.20 Does Not Allow Routine.Variable Specification

 Product Version(s): 2.20   | 2.20
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | S_PASCAL S_C H_FORTRAN H_MASM DOCERR
 Last Modified: 10-NOV-1989    ArticleIdent: Q50698

 On Pages 91-92 of the "CodeView and Utilities" manual that accompanied
 C 5.10 and Pascal 4.00 for CodeView Version 2.20, the period is
 documented as being useful as a specifier of local variables in parent
 functions. The syntax is stated to be as follows:

    routine_name.variable_name

 However, this feature was not implemented in Version 2.20 of CodeView.
 It was implemented in CodeView Version 2.30 (which accompanied FORTRAN
 5.00).

 This feature is useful in all languages, but particularly helpful in
 Pascal because of the "nested-scoping" (the ability of a function to
 access variables from the routine that called it) that occurs in
 Pascal.

 To use this feature in CodeView 2.30, you must be in either the
 routine where the variable is defined or in a routine that is a child
 (or grandchild, etc.) of that routine. After entering the proper
 routine, any variable name can be referenced with a routine and
 variable name (see example below).

 program first (input, output) ;
 var a: integer ;            { Available throughout the program }

     procedure second ;
     var b: integer ;        { Available in second and third }

         procedure third ;
         var c: integer ;    { Available in third }

         begin
             a := 3 ;
             b := 3 ;
             c := 3 ;
         end ;

     begin
         a := 2 ;
         b := 2 ;
         third ;
     end ;

 begin
     a := 1 ;                { Cannot watch second/third variables }
     second ;
 end.

 When in procedure third, you can place a watch on the variables in
 procedure second in the following manner:

 w? second.b

 This will display the variable in procedure second. This variable
 cannot be displayed from the main program, however.


 63. Using a Debugging Terminal with CodeView

 Product Version(s): 2.20
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 12-JAN-1989    ArticleIdent: Q39179

 It is possible to use either a dumb terminal or another machine (PC or
 Macintosh, running a communications package at 9600 baud) as a
 debugging terminal for CodeView. To take advantage of this option, do
 the following:

 1. Connect the second terminal to the com port (COM1 or COM2).

 2. Initialize the communications package to set up the
    second machine as a dumb terminal. Set the baud rate at
    9600.

 3. Start CodeView in either window or sequential mode.

 4. Redirect either the output ( >COM1 ) or both input and output
    ( =COM1 ) to the second terminal.

    If you redirect just the output to the second terminal, you will
    see the debugging output on the second terminal, and program output
    on the primary terminal. If you redirect input and output, you will
    also be able input program information (responses to prompts,
    input from the keyboard, etc.) on the primary terminal, and input
    CodeView information on the secondary terminal.

 5. Set your options and run the program.


 64. Pascal Version of CodeView Version 2.20

 Product Version(s): 2.20   | 2.20
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | S_PasCal
 Last Modified: 14-AUG-1989    ArticleIdent: Q39181

 CodeView Version 2.20 is different for Pascal then the rest of the
 languages. The Pascal version of CodeView 2.20 is the only version
 that has the Pascal Expression Evaluator. The way you can determine
 whether you are running the Pascal version is that Pascal will appear
 under the Languages menu.

 If you have multiple Microsoft Languages, you do not have to keep
 multiple versions of CodeView on your system. CodeView Version 2.20 is
 compatible with all of our languages. However, there is one exception
 -- if you are using Microsoft Pascal, make sure you use the version
 that came with Pascal. It is the only version that has the Pascal
 Expression Evaluator and all of the other language evaluators.

 To check if the version you have is the Pascal version, invoke
 CodeView and pull down the Languages menu. If it lists Pascal in the
 menu, you are using the Pascal version that is compatible with all of
 the Microsoft languages.


 65. "." on the LIBPATH Eases DLL Debugging, But Not for CVP 2.20

 Product Version(s): 2.20 2.30
 Operating System:   OS/2
 Flags: ENDUSER |
 Last Modified: 10-NOV-1989    ArticleIdent: Q50711

 When debugging OS/2 DLLs with protected mode CodeView (CVP), you must
 specify each DLL on the command line with an /L switch, and the DLL
 must be in the current directory as well as in a directory on the
 LIBPATH as set in CONFIG.SYS.

 For ease of debugging, if you put a period ("."), which means the
 current directory, as one of the directories on your LIBPATH, then a
 DLL in the current directory will also be on the LIBPATH and you won't
 need to have two copies of a DLL present on disk for debugging.

 This method only works for versions of CVP beginning with 2.30. CVP
 Version 2.20 will not recognize DLLs in a "." LIBPATH directory.

 If a copy of the DLL called by the program being debugged is not in
 the current working directory, you will not be able to trace into the
 DLL. If a copy of the DLL is not in a LIBPATH directory, CodeView will
 not be able to find the DLL. In this case, instead of coming up in the
 usual "debugging mode," CodeView immediately exits and returns to the
 command prompt after several seconds.

 Many DLL debugging problems arise from the fact that the copy of a DLL
 that is on the LIBPATH may be inadvertently out of date compared to
 the version in the current directory that is being used for debugging.
 By putting a period on the LIBPATH, the current directory becomes a
 LIBPATH directory and only one copy of the DLL needs to exist, thus
 eliminating any DLL update inconsistencies.


 66. CodeView Trace Skips Statement Following Switch Statement

 Product Version(s): 2.20 2.30 | 2.20 2.30
 Operating System:   MS-DOS    | OS/2
 Flags: ENDUSER | buglist2.20 buglist2.30
 Last Modified:  7-MAR-1990    ArticleIdent: Q59315

 CodeView incorrectly maps assembly level instructions to source code
 in the first statement following a switch statement with seven or more
 cases.

 As shown in the code sample below, the statement following the switch
 is executed correctly, but CodeView steps over the statement while
 tracing in source mode. In mixed source and assembly mode, the
 statement following the switch may be traced into.

 Sample Code
 -----------

 # include<stdio.h>

 void main(void)
 {

    short tag, marker;

    marker = 0;
    tag = 5;

    switch(tag){
       case 1:
          break;
       case 2:
          break;
       case 3:
          break;
       case 4:
          break;
       case 5:
          break;
       case 6:
          break;
       case 7:
          break;
       default:
          break;
    }

       marker = 2;

 }


 67. Using CodeView to Create Disassembled Program Listings

 Product Version(s): 2.20 2.30 | 2.20 2.30
 Operating System:   MS-DOS    | OS/2
 Flags: ENDUSER |
 Last Modified: 12-APR-1990    ArticleIdent: Q51323

 The following steps can be used to create an assembly listing of a
 program with CodeView:

 1. Begin CodeView in sequential mode by using the /T command-line
    switch.

 2. Specify a listing file to redirect CodeView output to by typing the
    redirection operator ">" followed by a filename at the dialog
    prompt. You may redirect the output directly to a printer by
    specifying the printer after the ">" (e.g., >PRN).

    (Note: From this point on, commands will not be viewable.)

 3. Use the Unassemble command "U" to disassemble the code and send a
    listing of the program to the output file. If you do not specify
    the starting address and the range to unassemble, CodeView will
    unassemble the next eight lines of code. See the CodeView
    documentation for more information on the Unassemble command.

 You can use this method on any files, whether or not they contain
 CodeView information. In this regard, you can create assembly listings
 of programs that were not created with a Microsoft compiler. Please
 also note that you cannot create assembly listings of instructions
 other than 8086 instructions.


 68. Debugging DLLs with Codeview

 Product Version(s): 2.20 2.30
 Operating System:   OS/2
 Flags: ENDUSER |
 Last Modified: 18-DEC-1989    ArticleIdent: Q51764

 To debug most DLLs (Dynamic Link Libraries) in CodeView, CVP
 (protected mode CodeView) Version 2.20 or later is required. For DLLs
 loaded via DosLoadModule(), CVP Version 2.30 or later is required.

 Invoke CodeView with the /L switch as follows:

    cvp /L dll1name /L dll2name main.exe

 Make sure that each DLL you want to trace into is specified by the /L
 option.

 CodeView cannot debug DLLs that have either IOPL or EXECUTEONLY
 specified with the CODE directive in the associated definition (.DEF)
 file. For DLLs that require these controls, the Kernel Debugger
 supplied with the SDK is required.

 Note: With CVP 2.30, pathnames cannot be specified for DLLs;
 therefore, the DLL must reside in the current directory. For more
 information, query on the following:

     CODEVIEW DLL LIBPATH


 69. Debugging Bound Applications

 Product Version(s): 1.00 1.10 2.00 2.10 2.20 | 1.11 2.02.02 2.20 2.30
 Operating System:   MS-DOS                   | OS/2
 Flags: ENDUSER | TAR63888
 Last Modified: 14-AUG-1989    ArticleIdent: Q25219

 CodeView does not support the debugging of bound applications in real
 mode. However, CVP in protected mode will allow you to debug such
 applications.


 70. No Symbolic Information Generated for Pascal Units

 Product Version(s): 2.20   | 2.20
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | s_pascal
 Last Modified: 12-JAN-1989    ArticleIdent: Q39811

 The Microsoft Pascal Compiler Version 4.00 generates no symbolic
 debugging information for Pascal Units. As a result, when tracing
 through a Pascal program Unit, attempting to access any local
 variables by using trace/watchpoints, dumps, examines, etc. yields a
 "symbol unknown" error.

 The only workaround is to transform the program Units into Modules.


 71. "Internal Debugger Error: 0" When Watching Structure Members

 Product Version(s): 2.20 2.30 | 2.20 2.30
 Operating System:   MS-DOS    | OS/2
 Flags: ENDUSER | buglist2.30 cv
 Last Modified: 29-DEC-1989    ArticleIdent: Q51834

 When watching a member of a structure using the "w?" or "?" commands,
 it is possible to get the message "internal debugger error: 0". When
 this happens, the only way to view the contents of the member is to
 use the "D" or "??" commands.

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

 typedef struct {
    char *(*instruction)[];
    } *structype;

 structype mac;

 void main (void)
 {
 }

 If you set a watch on an element of the structure variable in the
 above program such as "w? mac->instruction[0]" (without the quotation
 marks) you'll get the message "internal debugger error: 0." Use the
 dump command "D" or the special "??" structure viewing command to look
 at the contents of the member.

 Microsoft has confirmed this to be a problem in CodeView Version 2.30.
 We are researching this problem and will post new information here as
 it becomes available.


 72. Incorrect Error Generated for Very Small COM Files

 Product Version(s): 2.00 2.10 2.20 2.30
 Operating System:   MS-DOS
 Flags: ENDUSER | TAR65183 buglist2.00
 Last Modified: 21-AUG-1989    ArticleIdent: Q25365

 Problem:

 If my COM file is less than 8 bytes long and I try to load it into
 CodeView, I get the error message "Invalid executable file format -
 please relink."

 Response:

 This problem occurs only on COM files less than 8 bytes in length.

 Microsoft has confirmed this to be a problem with CodeView Version
 2.00. We are researching this problem and will post new information as
 it becomes available.


 73. Dual-Monitor Setup Requires 8-Bit Data Paths for Both Monitors

 Product Version(s): 1.00 2.00 2.10 2.20 2.30 | 2.20 2.30
 Operating System:   MS-DOS                   | OS/2
 Flags: ENDUSER | s_c s_pascal h_fortran h_masm b_basiccom
 Last Modified: 21-MAR-1990    ArticleIdent: Q51870

 When writing to a system that has a dual-monitor setup, you must make
 sure that both the monochrome monitor and the color monitor are using
 an 8-bit data path. In any dual-monitor write scheme, both display
 cards must be configured to write to a common data path (either both
 8-bit or both 16-bit mode). Today's monochrome adapters use 8-bit
 paths exclusively.

 Most display cards that use a 16-bit mode can autosense whether they
 are being written to in a dual-monitor mode, but some cards, such as
 the ATI VGA Wonder card, do not sense for this situation; therefore,
 you must set the card to an 8-bit path manually.

 If you are using dual monitors and you experience strange behavior
 such as garbage or blinking characters on the monochrome screen, make
 sure that your 16-bit video card is running in 8-bit mode.

 The most common use for a dual-monitor setup is for debugging graphics
 applications in CodeView.


 74. Retrieving Previously Entered Commands

 Product Version(s): 1.00 1.10 2.00 2.10 2.20 2.30 | 2.20 2.30
 Operating System:   MS-DOS                        | OS/2
 Flags: ENDUSER | TAR65921
 Last Modified: 14-AUG-1989    ArticleIdent: Q25539

 Question:

 Is there a method to retrieve commands after typing them in once? For
 instance, if I type "d some_data_area l 40", I would like to retrieve
 the command without having to retype it. A suggested method would be
 to allow the user to scroll on the command, then press a key to make
 the command active.

 Response:

 The only way to retrieve commands is to highlight them with the mouse
 and press the INS key. This method inserts the command into the
 command line. We are considering making an easier way to scroll
 through the commands and may implement it in a future version.


 75. system() Call May Cause CodeView to Terminate Process

 Product Version(s): 2.20 2.30
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist2.20 buglist2.30
 Last Modified: 22-JAN-1990    ArticleIdent: Q57867

 Using real-mode CodeView to trace over the system() run-time function
 will cause the debugger to terminate the parent process upon return
 from the child process in certain situations where the child does a
 multiple directory-level traversal.

 Instead of tracing, use the "Go" Command (F5) to run past the system()
 call. This procedure allows the program to run to completion.

 The program below demonstrates this problem, but it requires that
 TREE.COM be somewhere in the path. Compile the code with the /Zi and
 /Od options and use CodeView to trace into the program, using F8.
 After TREE.COM executes, CodeView will display the "Program terminated
 normally" message, preventing the last printf() from being executed.

 Microsoft has confirmed this to be a problem with CodeView Versions
 2.20 and 2.30. We are researching this problem and will post new
 information here as it becomes available.

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

 #include <process.h>
 #include <stdio.h>

 void main (void)
 {
         printf ("This is the beginning of the program\n");
         printf ("Calling TREE.COM\n");
         system ("tree");

         /* This line will never be executed */
         printf ("Back from spawn\n");
 }


 76. CodeView Versions 2.10 to 2.30 Use Four Extra File Handles

 Product Version(s): 2.30 2.20 2.10 2.00
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 19-JAN-1990    ArticleIdent: Q25950

 Problem:

 CodeView Versions 2.00 to 2.30 seem to be using four additional file
 handles. The following program attempts to open 20 files, reporting
 its success or failure after each attempt:

     #include <stdio.h>
     #include <string.h>
     #include <stdlib.h>

     main()
     {
             FILE *streams[20];
             int i;
             char buffer[12];
             char *p;

             for (i = 0; i < 20; i++) {
                     p = itoa(i, buffer, 10);
                     p = strcat(buffer, ".dat");
                     streams[i] = fopen(buffer, "w+");
                     printf("streams[%d] = %d\n", i, streams[i]);
             }
     }

 Running outside of CodeView, the call to fopen() fails after 15
 streams have been opened. Running in CodeView Versions 1.x, the call
 fails after 15 files have been opened. However, in CodeView Versions
 2.00 to 2.30, it fails after 11 file handles have been opened.

 Response:

 CodeView Versions 2.00 to 2.30 require four file handles for their own
 use. Remember that MS-DOS itself has five preopened file handles. If
 you want to open more than 15 files, follow the steps specified in the
 C Version 5.10 README.DOC to modify the C start-up code to allow
 opening more than 20 files.


 77. Copying Text from Display Window to Dialog Window

 Product Version(s): 2.20   | 2.20
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified: 12-JAN-1989    ArticleIdent: Q40110

 Question:

 Is it possible to copy text from the display window down to the dialog
 window to use at the command line in Microsoft CodeView?

 Response:

 Yes, if you have a mouse. You can highlight with the mouse the section
 of text you would like to copy and press the INSERT key. The
 highlighted text will appear in the dialog box.

 This is very useful if you have very long variable names that you want
 to watch and don't want to retype the long variable name each time.
 Simply type a w? on the command line, then highlight the variable name
 with the mouse and press the INSERT key.

 Strange behavior can occur if you use the SHIFT key in combination
 with the INSERT key. For example, if you use the INSERT key on the
 extended keyboard along with the SHIFT key, it works the same as using
 INSERT alone. However, if you turn NUM LOCK off on the keypad so you
 can you the INSERT key with the SHIFT key, you will get a zero instead
 of the string of text. To get the string of text, you have to turn NUM
 LOCK on. This seems backwards because with NUM LOCK on you would
 expect to get a zero, but you get the text.

 The workaround is not to use the SHIFT key in conjunction with the
 INSERT key. INSERT alone works correctly.


 78. OS2PATCH for CVP Not Needed in OS/2 Version 1.10.

 Product Version(s): 2.20 2.30
 Operating System:   OS/2
 Flags: ENDUSER |
 Last Modified: 14-NOV-1988    ArticleIdent: Q30976

    The OS2PATCH supplied with CodeView (protected) Versions 2.20 and
 2.30 allows you to use command 7 on machines with math coprocessors.
 This patch works only with OS/2 Version 1.00. The PTRACE feature was
 updated in Version 1.10, so this patch is not needed in OS/2 Version
 1.10.
    This patch only works on IBMs version of OS/2 1.00.  If they have
 a different version have them talk to the people who they received
 OS/2 from.  If it was from us then they need to systems languages
 support.
    Please refer to the file OS2PATCH.DOC for more information.



 79. I/O Redirection Under CV Not Supported Prior to Version 2.30

 Product Version(s): 1.x 2.10 2.20 2.30 | 2.20 2.30
 Operating System:   MS-DOS             | OS/2
 Flags: ENDUSER |
 Last Modified: 23-JAN-1990    ArticleIdent: Q57870
 In versions of CodeView earlier than Version 2.30, it was not possible
 to redirect the input or output of the program being debugged. For
 example, a "filter" program that takes input from a file specified by
 the input redirection operator ("<") is hindered by this limitation
 under pre-2.30 CodeView because there is no way to specify that you
 want the redirection to apply to the application rather than to
 CodeView itself.

 In CodeView (CV) or protected-mode CodeView (CVP) Version 2.30,
 redirection on the command line following the program name is directed
 to the program being debugged. For example, invoking CodeView 2.30
 with the following command line

    CV test < test.dat

 causes all input to the program TEST.EXE to be read from the file
 TEST.DAT.

 Redirecting I/O to CodeView itself is useful for involved debugging
 sessions where many CodeView dialog commands can be put into a
 separate text file that is automatically read by CodeView during
 debugging. For instance, this method will allow a complicated
 debugging scenario to be accurately repeated any number of times.
 Prior to CV and CVP 2.30, this was the only type of redirection
 supported while debugging.

 Starting with CodeView 2.30, you can redirect I/O to both the
 application being debugged and to CodeView. The CodeView redirection
 is done with the /C command-line option, or from within CV itself with
 the redirection dialog commands ("<" and ">"). Since the /C switch
 allows you to specify CV dialog commands on the command line, you can
 specify the redirection at this point. For example, the following
 command line

    CV "/C<cv.dat" test < test.dat

 brings up CodeView with TEST.EXE as in the example above (with the
 TEST.EXE input coming from TEST.DAT), but this time CodeView also
 reads the debugging instructions to perform from the file CV.DAT.


 80. /2 and /O Switches Not Compatible

 Product Version(s): 2.30
 Operating System:   OS/2
 Flags: ENDUSER |
 Last Modified:  9-NOV-1988    ArticleIdent: Q30978

    The UTILITY.DOC states that the /O switch is not compatible with
 the /2 switch. However, the SDK Installation Notes file uses the
 following code as the example of how to debug child processes:

     cvp /2 /O <program> <program arguments>

    This file recommends that the /2 switch be used when debugging PM
 applications. The UTILITY.DOC file is correct. You cannot use the /2
 and /O switches at the same time.


 81. CVP Prompts "SYS0197 OS/2 Not Configured..." Error Message

 Product Version(s): 2.20
 Operating System:   OS/2
 Flags: ENDUSER |
 Last Modified:  9-NOV-1988    ArticleIdent: Q31658

    When loading CodeView protected mode (CVP), the "SYS0197 OS/2 not
 configured to run this application" error message may appear. A
 request for help on 0197 prompts the "requires input/output privilege"
 message. You need to set IOPL=YES in CONFIG.SYS to run CVP.

    The following information is from the section titled "Microsoft(R)
 CodeView(R) Debugger" of the Microsoft C Version 5.10 UTILITY.DOC
 file, the FORTRAN Version 4.10 CVREADME.DOC file, and the Microsoft
 Macro Assembler Version 5.10 README.DOC file.

 CONFIG.SYS Setting for CVP
    To run the protected-mode CodeView debugger (CVP.EXE), you must
 have the following line in your CONFIG.SYS file:

    IOPL=YES



 82. Methods for Debugging Large Programs within the 640K DOS Limit

 Product Version(s): 1.00 1.10 2.00 2.10 2.20 2.30
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 12-FEB-1990    ArticleIdent: Q57941
 Because of the 640K limit under DOS, it is common to run out of memory
 when trying to debug large programs with CodeView. CodeView requires
 over 200K of RAM, not including the program being debugged. In
 addition, the symbolic information added by compiling with the /Zi
 switch greatly increases the executable size of the program you are
 trying to debug.

 The following is a list of the possible ways of getting around the
 limited memory problems for debugging:

 1. Include full symbolic information only in those modules that
    contain source code that you are currently trying to debug. In
    other words, compile only those modules with the /Zi switch. For
    the other modules, compile with the /Zd option, to put only line
    number information in the object files.

 2. Use overlays to swap parts of your code in and out, even if it is
    just during the development process. You can always link without
    overlays once your application is debugged.

 3. If you have expanded memory, use it by invoking CodeView with the
    /E switch. To work properly with CodeView, you should have LIM EMS
    3.2 or (preferably) 4.0. Expanded memory is used for storing the
    symbolic information, which can be a great percentage of your .EXE
    size.

 4. Use the CVPACK utility, which is documented in the Update Section
    of the C 5.1 "Microsoft CodeView and Utilities Software Development
    Tools for MS OS/2 and MS-DOS Operating Systems Update" manual.
    CVPACK will compress the debug information in the file by removing
    duplicate references. Use the /p option to achieve maximum
    compression.

 In trying to obtain a workable solution, you can use any combination
 of the above methods. If adequate debugging is still impossible, then
 you might look into the following possibilities:

 5. Switch to the OS/2 operating system. This may be limited as far as
    how much real mode program debugging you can do, depending on how
    compatible your application is with protected mode requirements.

 6. You might look into MagicCV from Nu-Mega Technologies of New
    Hampshire. MagicCV requires a 386-based computer because it uses
    virtual-86 mode of the processor to run CodeView in extended
    memory. This method reportedly allows CodeView to use only about 8K
    of conventional DOS memory. It should be noted that Microsoft does
    not endorse MagicCV or make any claims as to its usage. The
    information is offered only as a potential option. Nu-Mega can be
    reached at (603) 888-2386.


 83. Problems with CodeView and Logitech Mouse with Older Drivers

 Product Version(s): 2.00 2.10 2.20
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 23-JAN-1990    ArticleIdent: Q31918

 Incompatibility problems have been reported with Logitech's mouse and
 CodeView. Some of the problems encountered are as follows:

 1. The Logitech mouse fails to function correctly with CodeView
    Version 2.20 when in 43-line mode. The characters within
    highlighted cells are incorrect until they are unhighlighted.

 2. When in either 43-line or 25-line mode, garbage characters are
    occasionally found at the DOS prompt following an exit from
    CodeView.

 The problems seem to be with Versions 3.20 and earlier of the Logitech
 mouse driver. An update of the mouse driver is available that corrects
 these problems. Logitech can be reached at (415) 795-0427. Logitech
 also has a bulletin board service, which may contain the latest driver
 and can be reached at (415) 795-0408.

 A Microsoft Mouse or 100 percent Microsoft-compatible mouse is
 required for use with CodeView. In addition, you must use Microsoft's
 mouse driver Version 6.00 or later, or a driver that exactly emulates
 these Microsoft drivers.


 84. Using the T Command to Echo CodeView Output

 Product Version(s): 2.00 2.10 2.20
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 16-NOV-1988    ArticleIdent: Q31919

    To generate and record a history of the source lines stepped
 through in the course of a debugging session, do the following:

    1. Start CodeView in sequential mode using the /T option.
    2. While in sequential mode, enter the Redirect Output (>) command,
 followed by a filename. If no filename is specified, then stdout will
 be assumed.
    3. If you wish to view the output as it is redirected, precede the
 redirection operator with the echo command (T).
    4. If a second redirection operator is specified, the redirection
 file is appended to rather than truncated before output.

    For more information on output redirection, refer to the "System
 Commands" section of the "Microsoft CodeView and Utilities" manual.

    The following example demonstrates this process:

 CV> T > log.dat  or T >> log.dat
 CV> t
 CV> t
 CV> t
 CV> .
 CV> .
 CV> .
 CV> q

    The lines traced will be written both to the console and to the log
 file.


 85. CHAIN Statement in Compiled BASIC Not Supported by CodeView

 Product Version(s): 2.20
 Operating System:   MS-DOS
 Flags: ENDUSER | B_QuickBas B_BasicCom
 Last Modified: 16-NOV-1988    ArticleIdent: Q32265

    In Microsoft CodeView, when debugging compiled BASIC programs that
 CHAIN, you can view only the first program executed (the one given in
 the CV command line). The modules that are CHAINed-to cannot be viewed
 or stepped through, and their variables cannot be looked at, even if
 these modules are successfully executed. In fact, you cannot gain any
 information about the CHAINed modules, other than whether or not they
 execute correctly, unless you execute them separately in CodeView.
    This information applies to QuickBASIC Versions 4.00 and 4.00b,
 and the Microsoft BASIC Compiler Version 6.00 for MS-DOS and OS/2.



 86. CodeView Cannot Debug Source Code in Include Files

 Product Version(s): 1.00 1.10 1.11 2.00 2.02.02 2.10 2.20
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified:  9-NOV-1988    ArticleIdent: Q34922

 CodeView cannot debug source code in include files. This information
 is documented on Page 7 of the "Microsoft CodeView and Utilities"
 manual. The explanation for the restriction on include files says "You
 will not be able to use the CodeView debugger to debug source code in
 include files."

 This information means programs with include files that contain
 executable statements cannot be debugged with CodeView.

 The usual symptom of this problem is that after tracing or otherwise
 trying to execute your program, you will be viewing one of your
 include files instead of your normal source code. Repeated attempts
 to view the main or other source files will result in viewing the
 include file again.

 This is program design for the product. Microsoft's compilers do not
 generate symbolic information for code in include files. As a result,
 CodeView is confused by the discrepancies, and the subsequent behavior
 is unpredictable. Include files only can contain prototypes,
 declarations, #defines or #includes, etc.

 (Note that these items are all "nonexecutable" statements )

 Although it is valid C code, include files must not contain
 initializations or function definitions or other executable statements
 for CodeView to be able to debug your programs properly.


 87. No Symbolic Information Generated for Pascal Units

 Product Version(s): 2.10 2.20 2.30 | 2.20 2.30
 Operating System:   MS-DOS         | OS/2
 Flags: ENDUSER | s_pascal
 Last Modified:  8-MAR-1990    ArticleIdent: Q57943

 The Microsoft Pascal Compiler Version 4.00 does not generate symbolic
 debugging information for Pascal units. As a result, when tracing
 through a Pascal program unit, any attempt to access local variables
 by using trace/watchpoints, dumps, examines, etc. yields a "symbol
 unknown" error.

 The only workaround is to transform the program units into modules.


 88. CVP Accessing I/O Ports

 Product Version(s): 2.20 2.30
 Operating System:   OS/2
 Flags: ENDUSER | buglist2.20 buglist2.30
 Last Modified: 14-AUG-1989    ArticleIdent: Q36885

 In the "Microsoft CodeView and Utilities Software Development Tools
 for the MS-DOS Operating System," Sections 6.6 and 10.5 discuss the
 Port Input and Port Output commands respectively. These commands
 function correctly in CV under MS-DOS. However, CVP under OS/2
 generates a protection violation when trying to access a port. The
 port input and output commands do not function in CVP Version 2.20
 under OS/2.

 Microsoft has confirmed this to be a problem in Version 2.20. We are
 researching this problem and will post new information as it becomes
 available.


 89. Using CodeView to Examine FORTRAN Arrays

 Product Version(s): 2.20 2.30 | 2.20 2.30
 Operating System:   MS-DOS    | OS/2
 Flags: ENDUSER |
 Last Modified: 14-AUG-1989    ArticleIdent: Q37548

 Question:

 I have allocated memory for a three-dimensional array in FORTRAN. How
 can I examine the contents of a row using CodeView?

 Response:

 You can use CodeView to display a single element of the array using
 ?arrayname(x,x,x), where "arrayname" consists of the first six
 characters of the array name and "(x,x,x)" must be a valid cell in the
 array.

 There is no way to display more than one cell of the array using this
 command. To display many cells, you must do a memory dump of the
 addresses where the array is stored. Use the examine command (X) to
 get the starting address of the array, and dump (D) to dump the
 elements.

 FORTRAN stores array elements in column-major order. Use the following
 formula to determine the address where any cell (i,j,k) is stored,
 where Max_Row is the maximum i possible and Max_Col is the maximum j
 possible:

     MemAddr = start_addr+(size of elements)*
                      (Max_Row((k-1)(Max_Col)+(j-1))+(i-1))

 "Size of elements" is the number of bytes of each element in the
 array.


 90. CodeView Unexpectedly Exits to DOS

 Product Version(s): 2.10 2.20
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified:  8-APR-1990    ArticleIdent: Q37566

 When debugging a program with CodeView, certain operations cause it to
 exit to DOS without giving any warning or error message. Some of the
 things that cause this behavior are trying to access help, setting a
 watch variable, and returning from a DOS shell.

 This problem occurs because not enough file handles are being
 allocated at boot time with "files=XX" in CONFIG.SYS. An error message
 is printed, but then over written before most people can see it.

 The solution is to make sure files are set to 20 in CONFIG.SYS.


 91. How CodeView Handles DosExitList Routines

 Product Version(s): 2.20
 Operating System:   OS/2
 Flags: ENDUSER |
 Last Modified: 12-JAN-1989    ArticleIdent: Q40270

 Question:

 CodeView does not seem to be executing my DosExitList. What should I
 do to execute the exit list?

 Response:

 If you are in your program and issue the GO command, your program
 executes to the end of your application, giving the message "Thread
 terminated normally." At this point, you can use the GO command or
 trace into your exit routine. However, if you would like to quit your
 program and go to your exit handler in the middle of executing your
 program, you have two choices.

 When you quit CodeView ("q"), your code including your DosExitList
 will not be executed. The first method to execute your DosExitList is
 the safest, but you are not able to trace through your exit routine.
 When you want to exit, type the following:

    ? myexithandler()

 This command executes the function "myexithandler", which is your
 DosExitList routine. After this command has been performed, you can
 quit CodeView ("q") because all of your cleanup has been accomplished.

 The second method, which is less reliable, is to modify the instruction
 pointer (IP) so that you can effectively jump to the end of your
 program. Before you do this, make certain that you are not in a
 subfunction. If you are not in main(), jumping to the end of the
 program causes problems with the stack. While in your main() routine,
 enter the following at the CodeView command line, where XXXX is the
 value of the IP when you are at the last curly brace at the end of
 your program:

    R IP XXXX

 This command causes a jump to the last curly brace; you can step
 through your program from there. This method allows you to step
 through your exit routine, but it is a little more risky.


 92. You Cannot Display Past Column 71 in CodeView

 Product Version(s): 2.20   | 2.20
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified: 20-JAN-1989    ArticleIdent: Q40428

 Can I view my code beyond column 71 in CodeView like I can in the
 Microsoft editor?

 In CodeView Version 2.20, you cannot scroll your code to the right.
 You should either rewrite the source code or, if you used tabs in the
 source code, reduce the tab size with the # dialog command, as
 described on Page 240 of the "Microsoft CodeView and Utilities"
 manual.



 93. Display Command Returns Incorrect Result for FORTRAN Function

 Product Version(s): 2.20 2.30 | 2.20 2.30
 Operating System:   MS-DOS    | OS/2
 Flags: ENDUSER | buglist2.20 buglist2.30
 Last Modified: 14-AUG-1989    ArticleIdent: Q40586

 The display command does not return correct values for the
 user-defined FORTRAN real functions in Microsoft CodeView.

 The display command calls integer functions and returns correct
 results.

 Microsoft has confirmed this to be a problem in Version 2.20. We are
 researching this problem and will post new information as it becomes
 available.

 The display command is discussed in Chapter 6 of the "Microsoft
 CodeView and Utilities" manual. The valid FORTRAN expressions for
 CodeView are discussed in the Chapter 4 of the same manual.


 94. CodeView Does Not Work with Grouped Code Segments

 Product Version(s): 2.20   | 2.20
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | H_MASM
 Last Modified:  9-FEB-1989    ArticleIdent: Q40784

 When using MASM it is possible to associate various segments into a
 group; DGROUP is an example of this technique. Grouped data or stack
 segments do not affect CodeView, but CodeView does not recognize
 grouped code segments. The program will execute correctly under
 CodeView, but none of the CodeView functions will be available on the
 second and subsequent segments in the code group.

 The following code segment illustrates this behavior:

 codegroup  GROUP ASEG,BSEG
         assume cs:codegroup

 ASEG    SEGMENT WORD PUBLIC 'CODE'
 A:
         mov ax,1
         mov ax,1
         JMP B
 ASEG    ends

 ;   Will not be able to single step through this section
 BSEG    SEGMENT WORD PUBLIC 'CODE'
 B:      mov ax,1
         mov ax,1
         mov ax,1
         int 21h
 BSEG    ends
         end A

 Once the program executes into the BSEG segment, all CodeView
 functionality will be lost. You cannot set any breakpoints or single
 step through the BSEG segment of code. It appears that CodeView does
 not store any symbolic information for the BSEG segment. Any attempt
 to single step through this section of code will result in CodeView
 executing the BSEG segment of code until the program is completed.

 Microsoft is researching this problem and will post new information as
 it becomes available.


 95. CodeView and Video Pages

 Product Version(s): 2.00 2.10 2.20 | 2.20
 Operating System:   MS-DOS         | OS/2
 Flags: ENDUSER |
 Last Modified:  2-MAR-1989    ArticleIdent: Q41101

 Question:

 Is there anyway to specify which video page CodeView uses? I have an
 application that uses video page one; I am not able to use CodeView
 with it because CodeView also uses video page one.

 Response:

 CodeView does not allow you to specify which video page it will use.
 As a result, any application that uses video page one conflicts with
 CodeView and the screen becomes corrupted.

 The recommend work around in this situation is to use the two monitor
 option for CodeView. This option allows CodeView to send the
 application's output to one screen while using the first screen for
 its own output.

 Another less desirable workaround would be to avoid the use of video
 page one in programs that will be used under CodeView.



 96. Removing CodeView Information from .LIBs and .EXEs

 Product Version(s): 2.20   | 2.20
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | SR# G890207-11424
 Last Modified:  2-MAR-1989    ArticleIdent: Q41371

 Question:

 Is there a way to remove CodeView symbols from a .LIB or .EXE file?

 Response:

 Although there is no utility that removes CodeView information from
 libraries, EXEPACK will remove CodeView information from .EXE files in
 the course of packing them. You can also remove information from an
 .EXE file by relinking it without the /CODEVIEW option.

 The only way to remove CodeView information from a library is to
 recompile the source modules and use the LIB utility to rebuild the
 library.


 97. CodeView: Debugging Presentation Manager Printer Drivers

 Product Version(s): 2.20 2.30
 Operating System:   OS/2
 Flags: ENDUSER |
 Last Modified: 28-MAR-1989    ArticleIdent: Q42780

 To debug OS/2 Presentation Manager (PM) printer drivers, you must use
 the kernel debugger. Currently, PM printer drivers fall under the same
 category as lower-level device drivers. These device drivers cannot be
 debugged using the current version of CodeView.


 98. Dump Command on Arrays in FORTRAN Gives Syntax Error

 Product Version(s): 1.10 2.20 | 2.20
 Operating System:   MS-DOS    | OS/2
 Flags: ENDUSER | H_FORTRAN buglist2.20 buglist2.30
 Last Modified: 21-AUG-1989    ArticleIdent: Q42942

 Microsoft CodeView Versions 2.20 and 2.30 gives a "Syntax error" when
 attempting to use the Dump command on an array of dimension greater
 than 1.

 For example, issuing the DI i(1,3) command to dump the contents of an
 array element fails.

 To work around this problem use one of the following methods:

 1. Use the "?" command, as follows:

       ? i(1,3)

 2. Enclose each dimension index within parentheses and omit the comma,
    as follows:

       DI i((1)(3))

    DI i(1(3)) and DI i((1)3) are also acceptable.

    A three dimensional example would look like the following:

       DI j(1(2)3)

    Any permutation of the parenthesis around the index is sufficient.

 Microsoft has confirmed this to be a problem in Versions 2.20 and
 2.30. We are researching this problem and will post new information as
 it becomes available.


 99. CodeView Protect: /43 Switch Doesn't Work on VGA Adapters

 Product Version(s): 2.20
 Operating System:   OS/2
 Flags: ENDUSER | buglist2.20
 Last Modified: 18-APR-1989    ArticleIdent: Q43043

 The /43 switch for CodeView, used to debug in 43 line mode, is ignored
 when a VGA video adapter is being used under OS/2. This switch works
 properly as documented in DOS, or when an EGA adapter is being used.
 The /50 switch, used to debug in 50 line mode, also works properly as
 documented.

 If you wish to use CodeView Version 2.20 in 43 line mode under OS/2,
 the MODE command can be used first to set the entire screen group into
 43 line mode. Using MODE 80,43 at the OS/2 prompt will accomplish this
 result. Starting CodeView without any switches will then cause it to
 use the current video mode.

 Microsoft has confirmed this to be a problem in CodeView Protect
 Version 2.20. This feature is under review and will be considered for
 inclusion in a future release.


 100. CV: K Command in Secondary Module Sets Breakpoints in Main

 Product Version(s): 2.20   | 2.20
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | buglist2.20
 Last Modified:  6-APR-1989    ArticleIdent: Q43170

 In some cases the K (call stack) command will cause CodeView to become
 uncertain as to where to set breakpoints.

 If an attempt to set a breakpoint is made in a module of a
 multi-module program immediately after using the K command then the
 breakpoint will be set in the module containing main() instead of in
 the current module.

 If the corresponding line in the first module is not an executable
 line then CodeView will issue the expected beep to indicate that the
 breakpoint could not be set.

 If the corresponding line is an executable line then there will be no
 indication at all that the breakpoint has been set until that module
 is again in view. At that point the breakpoint will be highlighted as
 usual. This behavior will occur in any module accessed after the one
 containing main().

 Breakpoints will be set properly after using the K command if any
 stepping is performed, the view is changed, or the Calls menu is
 accessed.

 Microsoft is researching this problem and will post new information as
 it becomes available.


 101. Vertical Scroll Inactive with MODE CO40 and Dual Monitors

 Product Version(s): 2.x
 Operating System:   MS-DOS
 Flags: ENDUSER | S_C buglist2.20
 Last Modified: 18-APR-1989    ArticleIdent: Q43260

 While debugging a program using Microsoft CodeView and dual monitors,
 the vertical scroll bar is disabled when the video mode is set to
 40-line color text. This occurs if the mode is set either at the
 command line

    MODE CO40

 or from within a program as follows:

    _setvideomode(_TEXTC40);

 The scroll bar remains inactive until the mode is changed. This
 problem does not occur on a single monitor system or in any other
 video modes.

 Microsoft has confirmed this to be a problem in Version 2.20. We are
 researching the problem and will post new information as it becomes
 available.

 The following program demonstrates the problem:

 #include <graph.h>

 void main (void)
 {
   _setvideomode(_TEXTC40);
   _setvideomode(DEFAULTMODE);
 }



 102. Selecting Text for Use with Commands

 Product Version(s): 2.20 2.30 | 2.20 2.30
 Operating System:   MS-DOS    | OS/2
 Flags: ENDUSER | docerr insert
 Last Modified:  9-APR-1990    ArticleIdent: Q59408

 In CodeView Versions 2.20 and 2.30, you supposedly can press the left
 mouse button to highlight the command to be copied, and then press the
 INS key to copy the command. However, this method works only with the
 mouse and not with the keyboard.

 On Page 64 of the "Microsoft FORTRAN CodeView and Utilities User's
 Guide" Version 5.0 manual, it incorrectly states that you can copy any
 text that appears in any window. This is incorrect because you can
 only copy text in the command window.


 103. CodeView: View Command Fails with Underscore in Filenames

 Product Version(s): 2.20   | 2.20
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | buglist2.20
 Last Modified:  3-MAY-1989    ArticleIdent: Q43508

 Assume that two source files, MAINPROG.C and FILE_NAM.C, have been
 compiled with CodeView information. The main function in MAINPROG.C
 calls a function in FILE_NAM.C.

 When the following command is executed in CodeView, CodeView responds
 with "syntax error":

    V.FILE_NAM.C

 When FILE_NAM.C is renamed and recompiled as FILENAM.C, the following
 command works properly, and the source code in FILENAM.C is displayed:

    V.FILENAM.C

 Attempts to open a file with an underscore character will work
 correctly through the "Open" menu in CodeView, but will fail with the
 View command.

 Microsoft has confirmed this to be a problem in Version 2.20. We are
 researching this problem and will post new information as it becomes
 available.


 104. Cannot Set Breakpoint on an Executable Line with CodeView 3.00

 Product Version(s): 3.00   | 3.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified: 19-APR-1990    ArticleIdent: Q60338

 If you cannot set a breakpoint on a particular line of code, make sure
 you have used the -Zi and -Od options to create executable code that
 has full CodeView debugging capabilities.

 Some code in the executable is concatenated if the -Od option is not
 used.

 Sample Code
 -----------

 #include <stdio.h>

 int foo();

 void main (void)
 {
    int a,b,c;

    a = foo();/* this line would be concatenated into the next */
    b = a + c;/* line to look like b=(a=foo())+c.              */
 }

 int foo()
 {
    return(10);
 }


 105. Commands Invoked with "?" Command Must Be Compiled with /Zi

 Product Version(s): 2.20   | 2.20
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified:  3-MAY-1989    ArticleIdent: Q43556

 Invoking C functions in CodeView using the "?" command works as
 expected as long as the function is contained in a module that was
 compiled with /Zi for the CodeView information. However, if you invoke
 a run-time library function, CodeView returns the error message
 "syntax error."

 The reason for the error message is that the module containing the
 library function is not compiled with the CodeView option /Zi. The
 error message is not dependent on the fact that the function is in the
 library rather than being user-defined. If a user-defined function is
 contained in a module that is compiled without /Zi for the CodeView
 information and you try to invoke it with the "?" command, CodeView
 will return the same error message.

 The "?" command is formally referred to in the CodeView Utilities
 menu as the Display Expression command.


 106. CodeView May Single Step onto a Comment Line

 Product Version(s): 2.20   | 2.20
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | buglist2.20
 Last Modified:  2-JUN-1989    ArticleIdent: Q43601

 When using CodeView to single step the following program, the current
 execution line will be put on the first comment line. CodeView should
 always skip over the comment line.

 The program is compiled as required for running in CodeView. The
 compiling command used could be the following:

    cl /Zi /Od test.c

 Microsoft has confirmed this to be a problem with CodeView Version
 2.20. We are researching the problem and will post new information as
 it becomes available.

 This problem has no effect on the application program's performance.

 The following is the program:

 /*   test.c   */
 #include <stdio.h>
 int i = 1 ;
 void main (void)
 {
 if ( i )
      i = 0 ;
      /* first comment line */
 else
      /* more comment */
      i = 1 ;
 }


 107. Returning Control to CodeView

 Product Version(s): 2.20
 Operating System:   MS-DOS
 Flags: ENDUSER | CONTROL-C CONTROL+C CONTROL+BREAK CONTROL-BREAK ^C ^BREAK
 Last Modified:  3-MAY-1989    ArticleIdent: Q43648

 The following are two software methods of returning control to
 CodeView during program execution:

 1. Use the debug interrupt, interrupt 03, in your code. Interrupt 03
    is called a microprocessor (or logical) interrupt. It is the
    interrupt that CodeView uses to make breakpoints. Hard code
    interrupt 03 into your code in selected places where you want to
    return control to CodeView. The following sample program will
    demonstrate the technique. Note that a macro could easily be
    constructed to insert breakpoints where desired.

         #include <dos.h>
         #include <stdio.h>

         void main()
         {
             union REGS    inregs;
             int           i = 1;

             for( ;; )
             {
                 printf( "Loop iteration: %d\n", i++ );
                 int86( 0x03, &inregs, &inregs );
             }

 2. Use CTRL+C and CTRL+BREAK to return control to CodeView. This is
    a useful method for breaking out of a program is currently running
    or that has locked up.  The position in the source code to which
    you are returned depends on when you hit the ^C and what caused
    the system to hang, e.g. an infinite loop, a bad pointer, etc.
    Execution may be continued from this point in the usual manner
    (F5, F8, F10, etc.).

    Under OS/2 CTRL+BREAK does not return control to CodeView. CTRL+C
    may be used to abort a normally executing program but you cannot
    continue to debug from that point as you can in DOS.

 There is no hardware interrupt that will return control to CodeView.


 108. Cannot Open Source File Under CVP

 Product Version(s): 2.20
 Operating System:   OS/2
 Flags: ENDUSER | buglist2.20 buglist2.30 buglist2.4.1
 Last Modified: 18-SEP-1989    ArticleIdent: Q45135

 Problem:

 When using CodeView Protect (CVP) Version 2.20, I trace my program
 through a number of source files and after some number of files CVP is
 no longer able to open source files. When CVP gets into this
 situation, it automatically goes into mixed mode -- displaying line
 numbers but no source text. In this state, trying to use the "v"
 command to look at another (not previously looked at) file results in
 a red message box telling me that CVP can't open the file.

 Response:

 This is a problem with CVP Version 2.20 and 2.30. CVP is running into a
 file limit. To work around this problem, before you step out of the first
 module, open the source file containing the code you wish to debug and
 set a breakpoint there. Now "go" to this location by pressing the F5
 key. This procedure allows you to start debugging at a location deep
 into the file without opening multiple source files.

 Microsoft has confirmed this to be a problem with CodeView versions
 2.20 and 2.30. We are researching this problem and will post new
 information as it becomes available.


 109. Incorrect Handling of SP Can Cause CodeView to Corrupt Stack

 Product Version(s): 2.20 2.30 | 2.20 2.30
 Operating System:   MS-DOS    | OS/2
 Flags: ENDUSER |
 Last Modified:  7-JUN-1989    ArticleIdent: Q45183

 CodeView will use your program's stack for temporary variables in
 between assembly instructions. Thus, when writing an assembly language
 program, if you forget to increase the stack pointer (SP) to point
 beyond the memory locations you are using on the stack, CodeView will
 overwrite that memory.

 This is expected behavior. Even if CodeView did not use the stack, you
 would still have to increment the stack pointer to keep your program
 from overwriting your variables when you make a call, or with any
 operation that pushes values on the stack.


 110. Switching Out of PM Application Hangs System under Codeview

 Product Version(s): 2.20
 Operating System:   OS/2
 Flags: ENDUSER |
 Last Modified: 16-MAY-1989    ArticleIdent: Q44418

 Question:

 I am using CodeView to debug my Presentation Manager (PM) application.
 Why does my machine sometimes hang when I use CTRL+ESC to switch to
 the OS/2 program selector?

 Response:

 Presentation Manager applications require the use of the Presentation
 Manager shell. To debug PM applications, CodeView must put hooks into
 the Presentation Manager before the PM application is executed. This
 process works properly while inside CodeView, but if you try to switch
 back to the program selector, PM is in an unknown execution state.

 Therefore, to switch out of CodeView while debugging a PM application,
 you must first restart or end the program inside CodeView. This tells
 CodeView to restore the Presentation Manager to its original
 condition.


 111. SYS0317 Caused by Running CVP on a DOS Application

 Product Version(s): 2.20
 Operating System:   OS/2
 Flags: ENDUSER |
 Last Modified: 31-MAY-1989    ArticleIdent: Q44707

 The following message results from running a DOS application under
 Microsoft CodeView Version 2.20 or 2.30 for protected mode:

    SYS0317: The system cannot find message 0491
    in message file OSO001.MSG

 The screen is then cleared and the OS/2 prompt returns.


 112. /43 Starts CodeView with Screen Swapping Enabled

 Product Version(s): 2.20 2.30 | 2.20 2.30
 Operating System:   MS-DOS    | OS/2
 Flags: ENDUSER |
 Last Modified:  7-JUN-1989    ArticleIdent: Q45185

 When CodeView is started with the /43 switch to bring it up in 43-line
 mode, screen swapping is automatically enabled. This behavior is by
 design, although it is not stated in the documentation for the
 product.


 113. Setting a Breakpoint Highlights More Than One Line

 Product Version(s): 2.20
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist2.20
 Last Modified:  7-JUN-1989    ArticleIdent: Q45241

 When setting a breakpoint, CodeView may highlight two or more lines of
 code when you do the following:

 1. Compile C program (e.g., "Hello, world") with /Zi /Od.

 2. Load CodeView with 50 line mode (in VGA mode) as follows:

       cv /50 hello.c).

 3. Display mixed source and assembly.

 4. Move the cursor to the edit window and scroll down two or three
    pages of start-up assembly code.

 5. Set and remove breakpoints at arbitrary locations. In some cases,
    multiple lines will be highlighted and the display altered. The
    code itself is not changed. To restore the altered display, page
    down and then page up to the altered location.

 CVP does display this problem.

 Microsoft has confirmed this to be a problem in CodeView Version 2.20.
 We are researching this problem and will post more new as it becomes
 available.

 After setting a breakpoint that highlights more than one line of code,
 using the BL command will list only the one breakpoint you set.


 114. "No Symbolic Information" May Be Caused by Using Wrong Linker

 Product Version(s): 1.00 1.10 2.00 2.10 2.20 2.30 2.35 | 2.20 2.30 2.35
 Operating System:   MS-DOS                             | OS/2
 Flags: ENDUSER | S_LINK
 Last Modified: 19-SEP-1990    ArticleIdent: Q59540

 To debug programs at the source level with CodeView, it is critical
 that a proper version of LINK be used. Particular versions of CodeView
 are matched to particular versions of LINK and using a version of LINK
 newer than the versions matched to a particular version of CodeView
 will prevent CodeView from recognizing the symbolic information in the
 .EXE file.

 This mismatch will cause CodeView to come up in assembly mode and
 produce the message "No Symbolic Information," even though the source
 files may have been compiled and linked with the correct options for
 CodeView symbolic debugging.

 The difference between the linkers is in the way they store symbolic
 information in .EXE files. A newer version of CodeView generally can
 always display symbolic information for programs produced with
 previous versions of LINK, but the opposite is NOT true. Using a more
 recent linker with an older version of CodeView is where potential
 problems arise.

 The following information applies to both real-mode CodeView (CV) and
 protected-mode CodeView (CVP).

 Versions of CodeView prior to Version 3.00 cannot display symbolic
 information for .EXE files produced with LINK 5.10. In other words,
 if LINK 5.10 (supplied with C 6.00) is used for linking, then
 CodeView 3.00 is the ONLY matched version of CodeView that can
 display the program's symbolic information.

 CodeView Version 2.35 is matched to LINK 5.05 (both were released with
 BASIC 7.00). Therefore, CodeView 2.35 is the ONLY version of CodeView
 that can display symbolic information for a program linked with LINK
 5.05.

 For CodeView Versions 2.00, 2.10, 2.20, and 2.30, any linker with a
 version number from 3.60 to 5.03 is acceptable.

 For CodeView Versions 1.00 and 1.10, LINK versions later than or equal
 to 3.51, but earlier than 3.60, must be used.


 115. Mouse Disabled When Single-Stepping over Video Mode Change

 Product Version(s): 2.20 2.30
 Operating System:   OS/2
 Flags: ENDUSER | buglist2.20 buglist2.30
 Last Modified: 21-JUN-1989    ArticleIdent: Q45617

 When CodeView is run in the OS/2 compatibility box with screen
 swapping enabled (started with either /s or /43), single-stepping (F8)
 over a _setvideomode() call or an INT 10 call to change the video mode
 to a graphics mode causes the mouse cursor to disappear. Exiting
 CodeView and running another mouse-driven program reveals that the
 mouse has been completely disabled in the compatibility box. The only
 way to regain the mouse is to reboot the computer. Attempting to
 reload the mouse by typing "mouse" at a prompt results in the
 following message:

    Session Title: DOS Command Prompt

 This error occurs because a DOS mode program changes an interrupt
 vector that is owned by the system causing the program to end.

 The behavior described above applies to tracing in SOURCE mode.
 Attempting to trace in assembly language or mixed mode through the
 code that changes the video mode produces erratic results, which range
 from hanging the DOS box to halting the entire system with an
 "internal processing error."

 Microsoft has confirmed this to be a problem in CodeView Versions 2.20
 and 2.30. We are researching this problem and will post new information
 as it becomes available.

 The following program illustrates the problem:

 #include <graph.h>

 void main(void)
 {
   _setvideomode(_ERESCOLOR);    /* when this line is executed, the  */
                                 /* mouse cursor will disappear.     */
   _setvideomode(_DEFAULTMODE);

 }


 116. CodeView "??" Command Can't Show All of Large Structures

 Product Version(s): 2.20 2.30 | 2.20 2.30
 Operating System:   MS-DOS    | OS/2
 Flags: ENDUSER | SR# G890607-19918
 Last Modified:  8-AUG-1989    ArticleIdent: Q45624

 Question:

 How can I view structures with many members in CodeView with the "??"
 command? It shows only those members that fit on the screen. Is there
 some trick I haven't found?

 Response:

 Unfortunately, the "??" command is limited in this respect -- there is
 no way to view the last members of a large structure with this
 command. This feature is under review and will be considered for
 inclusion in a future release.

 Instead, however, you can view each element of the structure by itself
 by dereferencing the struct and element, i.e., "?structname.field".

 There are at least two ways to work around the problem in CodeView
 Versions 2.20 and 2.30. One way is to shrink or nest the structures.
 Another workaround is to use the "?" or Watch command to look at the
 individual member(s) you want to see.


 117. Problem Debugging StartSession from a Child Process

 Product Version(s): 2.30
 Operating System:   OS/2
 Flags: ENDUSER | buglist2.30
 Last Modified:  9-AUG-1989    ArticleIdent: Q45707

 When a program spawns another program that starts a new session,
 CodeView has difficulty stepping into that new session. This process
 is shown graphically in the following diagram:

        --------------        -------------------
    A --| DosExecPgm |--> B --| DosStartSession |--> C
        --------------        -------------------

 The following describes how to duplicate this process and re-create
 the problem:

 1. Invoke CodeView on Program A with offspring debugging enabled, as
    follows:

       CVP /O A

 2. Program A calls DosExecPgm to spawn Program B. Trace into Program B
    by pressing F8 on the DosExecPgm function. You will be informed
    that a new process has begun and you will be asked if you wish to
    debug it. Answer yes and switch to the newly created CodeView
    session.

 3. Program B calls DosStartSession to begin a new session. The program
    that will execute in that session is Program C. Attempt to trace
    into the new session by pressing F8 on the DosStartSession function.

 The problem is demonstrated in Step 3. CodeView does not give you the
 opportunity to debug Program C as it should. Further, when Program B
 has completed execution and CodeView returns back to Program A, the
 first single step will inform you that a new process has been started.
 This message should have been presented on the call to
 DosStartSession.

 CodeView has no difficulty stepping into a new session when the
 initial program being debugged is Program B. To work around this
 problem, invoke CodeView on Program B with the /O switch.

 Microsoft has confirmed this to be a problem with CodeView Version
 2.30. We are researching this problem and will post new information
 as it becomes available.

 The following three modules demonstrate this problem:

 //***********************************************************
 // A.C - spawn a child from here.

 #define INCL_BASE
 #include <os2.h>

 void main (void)
 {
   char        failbuf[80];
   RESULTCODES ExecCode;

   DosExecPgm (failbuf, 40, EXEC_ASYNC, NULL, NULL, &ExecCode, "B.EXE");
   VioWrtTTY ("End of A.\r\n", 11, 0);
 }

 //***********************************************************
 // B.C - start a new session from here.

 #define INCL_BASE
 #include <os2.h>
 #include <string.h>

 void main (void)
 {
   USHORT    Disk;
   ULONG     Drives;
   BYTE      SessionProg [80];
   USHORT    MaxLen = sizeof(SessionProg)-14;
   STARTDATA StartData;
   USHORT    Session;
   USHORT    Process;

   // Build program name to run in new session.
   DosQCurDisk (&Disk, &Drives);
   strcpy (SessionProg, "*:\\");
   SessionProg[0] = (char) ('A' + Disk - 1);
   DosQCurDir (0, SessionProg + strlen(SessionProg), &MaxLen);
   strcat (SessionProg, "\\C.EXE");

   StartData.Length      = sizeof(STARTDATA);
   StartData.Related     = 1;
   StartData.FgBg        = 0;
   StartData.TraceOpt    = 0;
   StartData.PgmTitle    = "Test Session";
   StartData.PgmName     = SessionProg;
   StartData.PgmInputs   = "sample param";
   StartData.TermQ       = NULL;
   StartData.Environment = NULL;
   StartData.InheritOpt  = 0;
   StartData.SessionType = 1;
   StartData.IconFile    = NULL;
   StartData.PgmHandle   = 0;

   DosStartSession (&StartData, &Session, &Process);
   VioWrtTTY ("End of B.\r\n", 11, 0);
 }

 //***********************************************************
 // C.C - the test session.

 #define INCL_VIO
 #include <os2.h>

 void main (void)
 {
   VioWrtTTY ("In test session", 15, 0);
 }


 118. CodeView Skips Over a Line of Source Code

 Product Version(s): 2.20 2.30 | 2.20 2.30
 Operating System:   MS-DOS    | OS/2
 Flags: ENDUSER | S_QuickC
 Last Modified: 14-AUG-1989    ArticleIdent: Q46010

 After setting a breakpoint on the indicated line in the program below
 and executing the program, CodeView executes that line without
 stopping. Likewise, if you single step through the code, CodeView
 steps past that line. This problem also occurs in the QuickC
 integrated debugger.

 The workaround is to flip your source into mixed mode and set the
 breakpoint on the correct assembly line.

 This is due to the fact that CodeView is line-based and the C compiler
 is token-based. This will not be corrected; it is a restriction.

 Sample Program
 --------------

 int i, j, k, l;

 void main(void)
 {
     for(i = 0; i < 20; i++)
     {
         j = 0;
         for(k = 0; k < 20; k++)
             if(j == 0)
                 break;

         j = 1; /*** set breakpoint here ***/
     }

     l = 0;
 }


 119. Capabilities and Limits of the /R switch on 80386 Machines

 Product Version(s): 2.20 2.30 2.35 3.00 | 2.20 2.30 2.35 3.00
 Operating System:   MS-DOS              | OS/2
 Flags: ENDUSER | 386
 Last Modified: 12-APR-1990    ArticleIdent: Q46448

 The /R command line switch for CodeView beginning with Version 2.20 is
 used only on 80386 machines. The /R switch tells CodeView to use the
 four debug registers available on the 80386 chip, and also allows
 hardware breakpoints. This causes CodeView to run faster when
 performing debugger-intensive steps such as monitoring a tracepoint.

 The /R switch works under DOS and OS/2's DOS compatibility box. It is
 an unrecognized switch under OS/2. The /R switch speeds operation of
 Tracepoint but not Watchpoint or Breakpoint commands.

 Note: because there are only four debug registers, only four
 tracepoints (of up to 4 bytes each) may be specified when utilizing
 these registers. Specifying any combination of tracepoints greater
 than 16 bytes will require CodeView to use software tracepoints rather
 than the debug registers and all performance gains will be lost.


 120. Using CodeView /2 with Hercules Graphics Cards and Libraries

 Product Version(s): 2.20 2.30
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 16-OCT-1990    ArticleIdent: Q46949

 Using CodeView in the dual-monitor mode with a Hercules graphics card
 as the primary (application) monitor requires the Hercules card to be
 configured in the half mode. Using the Hercules graphics library, the
 monitor must be configured using the config(0) function call. This
 function call is a part of the Hercules graphics library and does not
 use Microsoft graphics library or the MSHERC.COM program. Therefore,
 this information applies only if you are using the Hercules graphics
 libraries. This is NOT the same as using the /h switch with CodeView.

 The first page of the Hercules graphics display card is mapped to
 memory location B0000 (same as MDA), and the second page is mapped to
 B8000. The CGA/EGA/VGA also use B8000 as the beginning of their video
 memory. CodeView uses these two different address to run in the
 dual-monitor mode, sending the application output to the primary
 address, usually located at B8000, and the CodeView information to the
 secondary monitor, usually located at B0000.

 This works well until a Hercules graphics card is used as the primary
 monitor (in graphics mode) and the CGA/EGA/VGA card is used as the
 secondary monitor. The Hercules graphics card uses both pages (one at
 B0000 and the other at B8000) in the full mode. Therefore, use
 config(0) and only the first page (B0000) will be used and CodeView
 will function properly in dual-monitor mode.


 121. DEF File Entry of EXECUTEONLY Causes Problems with CVP

 Product Version(s): 2.20 2.30
 Operating System:   OS/2
 Flags: ENDUSER |
 Last Modified: 30-AUG-1989    ArticleIdent: Q47103

 Question:

 When I step into my DLL, I can see and step through the source code
 correctly. I also can look at local variables. However, I cannot set
 breakpoints in the DLL. Also, when I try to look at the disassembled
 code I see the following:

    ??? No Code ???

 I am using the correct Compile and Link options. Why is CodeView
 acting strangely?

 Response:

 In the .DEF file for the DLL, you had the EXECUTEONLY attribute as
 opposed to the default EXECUTEREAD. When you choose EXECUTEONLY,
 CodeView cannot read the code segment as it must to work correctly.
 Removing the EXECUTEONLY attribute corrects the problem.


 122. OS/2 SDK Version of CVP 2.30 Won't Debug DosLoadModule DLLs

 Product Version(s): 2.30
 Operating System:   OS/2
 Flags: ENDUSER |
 Last Modified: 11-JUL-1990    ArticleIdent: Q59610

 The OS/2 version 1.10 Software Development Kit (SDK) includes a
 prerelease version of protected-mode CodeView (CVP) version 2.30. This
 version is identical to the regular retail release of CVP 2.30, except
 that it does not allow the debugging of DLLs loaded with
 DosLoadModule. The regular retail version of CVP 2.30 is included with
 FORTRAN 5.00 and the OS/2 Presentation Manager Toolkit for OS/2
 version 1.10. This release DOES support debugging DLLs loaded at run
 time with DosLoadModule.

 The prerelease version of CVP 2.30 released in the OS/2 SDK may be
 identified by a file date of 2-24-89. The regular release version is
 dated 3-21-89. The file date is the only discernible difference
 between these two versions since the files themselves are exactly the
 same size.


 123. Minimum Extended Memory (384K) Causes CV 3.00 to Use Extra RAM

 Product Version(s): 3.00
 Operating System:   MS-DOS
 Flags: ENDUSER | docerr HIMEM
 Last Modified: 27-SEP-1990    ArticleIdent: Q59890

 Real-mode CodeView (CV) Version 3.00 is documented as being able to
 run in extended memory as long as there is at least 384K of extended
 memory available. This 384K minimum is accurate as far as CV being
 able to utilize the extended memory, but it is not enough for CodeView
 to remove all of itself from conventional RAM. In fact, a system
 configuration with only 384K extended memory will result in LESS
 memory being available for the debuggee (the program being debugged)
 than if no extended memory is utilized at all.

 The CodeView 3.00 documentation states that "if HIMEM.SYS or another
 extended-memory driver is installed, all but 16K of CodeView, plus all
 of the symbolic information for the program you are debugging, are
 placed in extended memory." But, for CodeView to truly work with this
 16K "footprint" in conventional memory, a minimum of approximately
 600K extended memory must be available.

 When no extended memory is available, CodeView normally utilizes
 overlays to keep as much of itself out of memory as possible, so that
 the debuggee can have more space to load. (The new /Dnnn option
 actually allows you to specify the size of the overlays -- a bigger
 overlays means CV runs faster, but a smaller overlays mean a bigger
 program can be loaded for debugging.)

 Once CodeView detects extended memory, it assumes that overlays are no
 longer needed, since CV itself and the debuggee's symbolic information
 will both (supposedly) be loaded into extended memory. However, the
 result may be that CodeView seems to get bigger because what Codeview
 can't fit into extended memory is loaded into conventional memory.

 Since no overlays are used, this can result in a much larger
 footprint. For instance, if the minimum of 384K extended memory is all
 that is available, then the footprint will be well over 200K.
 Obviously, as the amount of extended memory is increased from 384K,
 the footprint will shrink accordingly.

 The /X command-line option instructs CodeView to use extended memory.
 However, CV will automatically detect extended memory and use it if it
 is available. Consequently, if the /X option is not specified, CodeView
 will still use extended memory.

 Thus, if you have a limited amount of extended memory and decide to
 run CodeView in conventional RAM only, you have two options. You can
 explicitly specify /D (for example, /D16) to tell CodeView to use
 overlays, or you can remove (or comment out) the line in your
 CONFIG.SYS file that loads the extended memory driver (HIMEM.SYS) and
 reboot.


 124. If COMSPEC Is Invalid, Invoking DOS Shell May Hang Machine

 Product Version(s): 2.x 3.00
 Operating System:   MS-DOS
 Flags: ENDUSER | s_quickc s_pwb s_quickasm s_editor
 Last Modified: 19-APR-1990    ArticleIdent: Q60748

 If you set your COMSPEC environment variable to point to an invalid
 command interpreter, and then shell out of any DOS application, your
 machine will hang. This problem occurs because the file that COMSPEC
 points to is assumed to be a valid command interpreter and cannot be
 checked for validity.

 This is expected behavior. Because .COM files have no standard file
 header structure, they cannot be checked for validity. Therefore, DOS
 must assume that whatever the COMSPEC environment variable points to
 must be a valid command interpreter, and can do no further error
 checking.

 This behavior can easily be demonstrated in any program that allows
 you to access a DOS shell, including CodeView, Programmer's WorkBench
 (PWB), the Microsoft Editor (M), and the Quick environments. Type the
 following line at the DOS prompt:

    set comspec=a:\foo.c ; Invalid command.com file

 Then enter a DOS application and shell out. Your machine will hang,
 and you may receive strange error messages.

 If you are running under OS/2, you will be warned about an invalid
 command interpreter when you attempt to shell to the operating system.
 Under OS/2, the system expects an .EXE file to be the command
 interpreter, and .EXE files have a standard, recognizable structure
 that can be checked.


 125. /I Documented Incorrectly in "Advanced Programming Techniques"

 Product Version(s): 3.00   | 3.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | docerr
 Last Modified: 19-APR-1990    ArticleIdent: Q60829

 In Section 9.7, "Controlling CodeView with Command-Line Options," on
 Page 204 of the "Microsoft C Advanced Programming Techniques" manual,
 it incorrectly states that the /I switch (used to turn the nonmaskable
 interrupts and 8259 interrupts on or off) is followed by either a 1 or
 a 2 (either /I1 or /I2).

 The correct switch options are /I0 to trap these interrupts, or /I1 to
 ignore these interrupts. Both the online documentation and the
 "Microsoft C Reference" give this correct usage of the /I switch.


 126. OS/2 1.20 Requirements for Dual-Monitor Debugging

 Product Version(s): 2.x 3.00
 Operating System:   OS/2
 Flags: ENDUSER | PM
 Last Modified: 17-JUL-1990    ArticleIdent: Q60866

 To do dual-monitor debugging under OS/2 Version 1.20 with CodeView,
 make sure that you have the correct display DLLs specified in your
 CONFIG.SYS file.

 For example, the following three lines in your OS/2 CONFIG.SYS file
 specify the device drivers needed to use a VGA and a monochrome
 adapter:

    set video_devices=bvh_vga,bvh_mpa
    set bvh_vga=device(bvhvga)
    set bvh_mpa=device(bvhmpa)

 If you have a CGA or an EGA monitor and adapter for your primary
 (color) display, replace device(bvhvga) with device(bvhcga) or
 device(bvhega), depending on your adapter type.

 Next, make sure that both of the BVH*.DLL files (in the above case,
 BVHVGA.DLL and BVHMPA.DLL) specified in the device(name) section are
 in your LIBPATH. OS/2 setup places these files in your C:\OS2\DLL
 directory by default.

 Note: You can substitute any name for bvh_vga or bvh_mpa, as long as
 those two placeholders match up with the name tab in the set
 <name>=device... lines.

 Remember, the two monitors must be unique for OS/2 to determine which
 monitor is which. For instance, debugging with two VGA monitors will
 not work because OS/2 and, therefore, CodeView will be unable to
 determine which adapter/monitor is the primary adapter/monitor and
 which is the secondary adapter/monitor.

 This point is critical to remember when considering dual-monitor
 debugging on a microchannel machine (for example, an IBM PS/2 Model 50
 and above). Since there are currently no microchannel monochrome
 adapter cards on the market, the only alternative is to use a VGA and
 an 8514 as the two monitors. The following are the matching three
 lines for your OS/2 CONFIG.SYS file for that scenario:

    set video_devices=bvh_vga,bvh_8514
    set bvh_8514=device(bvh8514)
    set bvh_vga=device(bvhvga)

 Using this setup, the 8514 monitor displays the graphics output (or
 the Presentation Manager screen) and the VGA is the debug monitor and
 displays all text output.


 127. Debugging Large DOS Applications in CodeView 3.0 with /X /E /D

 Product Version(s): 3.00
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 15-MAY-1990    ArticleIdent: Q61473

 CodeView version 3.00 includes enhanced support for debugging
 applications under DOS. CodeView 3.00 may access extended memory or
 expanded memory, or the size of the overlay swap area that CodeView
 uses may be adjusted.

 CodeView 3.00 offers three command-line parameters (/X, /E, and /D)
 for specifying memory utilization. If you DO NOT specify the /X, /E,
 or /D options when you start a CodeView session, CodeView will
 automatically search for extended memory. If CodeView finds extended
 memory, it will place the symbolic information and most of itself into
 extended memory (as long as enough extended memory is available).

 If there is no extended memory on your system, Codeview will search
 for expanded memory. If there is expanded memory, Codeview will place
 the symbolic information for your program in expanded memory.

 If there is no extended or expanded memory on your machine, CodeView
 will load itself, your application, and symbolic information for your
 program in base memory.

 Since CodeView does this automatic scan for extended and expanded
 memory, the /X and /E switches are needed only if you explicitly want
 to specify the use of one form of memory or the other and you do not
 want to enter CodeView if this memory type is not available.

 CodeView's /X option tells the debugger to load into extended memory
 ONLY, and to return an error message if extended memory is not
 available on your system. This message has the following form:

    CV1302 Error: /X : HIMEM.SYS not loaded

 CodeView's /E option tells the debugger to access expanded memory
 ONLY, and to return an error message if there is no expanded memory on
 your machine. This message has the following form:

    CV1304 Error: /E : EMM driver not loaded

 CodeView's /D option specifies that CodeView should use disk overlays.
 When you use this option, you can also specify a decimal size in
 kilobytes between 16K and 128K to explicitly set the overlay swap area
 size. The default size of the swap area is 64K if /D is used but no
 size is explicitly specified. If extended and expanded memory are not
 available, /D will not need to be specified for the default 64K
 overlay swap area to be used.

 A larger overlay swap area allows CodeView to run faster because it
 doesn't have to swap to disk as frequently as with a smaller swap
 area, but it means more memory is used up by CodeView itself. A
 smaller swap area allows you to debug larger applications under DOS,
 but CodeView runs slower because of the more frequent need to swap
 code from disk to memory.


 128. P70 Display Creates Problems Under CodeView and PWB

 Product Version(s): 3.00
 Operating System:   OS/2
 Flags: ENDUSER | buglist3.00 S_PWB S_Editor
 Last Modified: 15-AUG-1990    ArticleIdent: Q61557

 CodeView version 3.00 and Programmer's WorkBench (PWB) version 1.00
 have problems recognizing the built-in monitor of IBM P70 portables
 under OS/2. Symptoms of this problem include the following error
 messages:

    Product     Error Message
    -------     -------------

    CodeView    Internal Debugger Error 0 at load time
    PWB         Inability to change from 43-line mode

 Microsoft has confirmed this to be a problem with CodeView version
 3.00. We are researching this problem and will post new information
 here as it becomes available.

 This problem is directly related to the video configuration of the IBM
 P70. In its documentation, IBM mentions briefly that it might be
 necessary to type MODE CO80 to make some software recognize the
 built-in plasma display. An added condition for PWB and CodeView is
 the necessity of being in 43-line mode. PWB automatically places you
 in 43-line mode no matter what you previous mode was and thus gets
 around this limitation. If you attempts to change the height switch
 while editing, PWB doesn't complain but still stays in 43-line mode.

 CodeView cannot make the mode change in the same way that PWB can. If
 invoked without the above considerations, CodeView will crash with an
 Internal Debugger Error 0. The following are several ways to work
 around this problem if want to use CodeView with this type of
 configuration.

 1. Type MODE CO80 or BW80 and invoke CodeView with the /43 switch.

 2. Type MODE CO80,43 or BW80,43 before invoking CodeView.

 3. Use an external monitor with the built-in VGA port.

 4. Invoke CodeView from PWB, which makes the change automatically.


 129. CodeView Does Not Reset Initial Graphics Mode on Exit

 Product Version(s): 2.x 3.00    | 2.x 3.00
 Operating System:   MS-DOS      | OS/2
 Flags: ENDUSER |
 Last Modified: 29-MAY-1990    ArticleIdent: Q61611

 When CodeView exits, it leaves the screen in the current video mode
 and does not reset the mode to the mode that was active when CodeView
 was initially loaded.

 This behavior is by design. However, if you start CodeView with the /s
 option to enable screen swapping, the video mode that was active when
 CodeView was loaded will be reset because CodeView has separate
 swappable video memory pages to hold the output screen as well as the
 CodeView screen.


 130. CV 3.00 Gives R6000, Hangs When Accessing Help During Start-Up

 Product Version(s): 3.00
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist3.00 fixlist3.10
 Last Modified:  5-FEB-1991    ArticleIdent: Q61919

 Accessing help in the "Enter directory for filename.c (cr for none)?"
 window results in the following error in CodeView version 3.00:

    run-time error R6000
    -stack overflow

 Then, the machine hangs requiring a cold reboot.

 To reproduce the error, do the following:

 1. Compile and link a program with symbolic information for CodeView.

 2. Delete or rename the source file and then go into CodeView. A
    window will appear asking you to "Enter directory for filename.c
    (cr for none)?".

 3. Choose the Help option at the bottom of the window. The run-time
    error message will be printed over the CodeView screen and the machine
    will be hung.

 The problem does not occur under OS/2.

 Microsoft has confirmed this to be a problem in CodeView version 3.00.
 This problem was corrected in CodeView version 3.10.


 131. CodeView 3.00 Fades with Monochrome VGA

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

 If you invoke CodeView version 3.00 on certain machines with
 monochrome VGA monitors and then trace through several lines of code,
 the screen will fade and become unreadable. Exiting and re-entering
 CodeView refreshes the screen, but the screen immediately starts to
 fade again.

 This problem is caused by an error in the video ROM BIOS and has been
 verified to occur on the following machines:

 l. PS/2 Model P70 with monochrome VGA

 2. Siemens with Video 7 monochrome VGA

 3. Northgate 386 with Video 16 monochrome VGA

 The following are different methods of working around this problem:

 1. Switch into color mode using the mode CO80 command (may not have
    any effect).

 2. From the options menu inside Codeview, turn flip/swap off using
    the screen-swap option.

    If you don't want to give up flip/swap functionality, try option 3.

 3. If the video BIOS is replaceable, replace it with an updated video
    BIOS.

 4. If the video BIOS is not replaceable, replace the card.


 132. CodeView 3.00 Hangs on gets() with Screen Swap Off

 Product Version(s): 3.00   | 3.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | s_c s_quickc s_quickasm
 Last Modified: 25-JUL-1990    ArticleIdent: Q62663

 CodeView 3.00 will hang if you step or execute past a call to the
 gets() run-time routine if the Screen Swap option is turned off.

 Sample Code
 -----------

 #include <stdio.h>

 char string[256];

 void main (void)
 {
     printf ( "Enter a string: ") ;
     gets ( string ) ;
     printf ( "Echoing : %s\n", string) ;
 }

 Compile the above file with the following:

    cl /Od /Zi test.c

 Bring the file up in CodeView, then select the Options.Screen Swap
 option. Next, step past the gets() call. Under DOS, your machine will
 hang, and under OS/2, the current screen group will be hung.


 133. DosSetMaxFH Between 0-39 Fails Under CodeView 3.00

 Product Version(s): 3.00
 Operating System:   OS/2
 Flags: ENDUSER | buglist3.00
 Last Modified: 25-JUL-1990    ArticleIdent: Q62666

 OS/2's DosSetMaxFH routine can be called to reset the OS/2 default
 limit of a maximum of 20 open file handles to a larger number. By
 definition, DosSetMaxFH fails when trying to set the number smaller
 than the current maximum amount of handles. Under OS/2, the default
 maximum number of files is 20, so a DosSetMaxFH to a number between
 0-19 should fail.

 However, under CodeView 3.00, calling DosSetMaxFH with a number
 between 0-39 will return a fail value.

 Sample Code
 -----------

 /* compile with : cl /Od /Zi file.c */

 #define INCL_DOSFILEMGR

 #include <stdio.h>
 #include <os2.h>

 void main(void)
 {
    int i;
    for ( i = 0 ; i < 1000 ; i ++ )

    if ( DosSetMaxFH ( i ) )
    {
       printf ( " DosSetMaxFH to %d failed!\n ",i ) ;
    }
 }

 This program prints the error message on parameters from 0 to 39.

 You can call the DosSetMaxFH routine to set at least 40 file handles
 to work around this problem.


 134. CV Limits Input of Period Character (2Eh) into Memory Window

 Product Version(s): 3.00 3.10 | 3.00 3.10
 Operating System:   MS-DOS    | OS/2
 Flags: ENDUSER | buglist3.00 buglist3.10 decimal point dot
 Last Modified: 31-AUG-1990    ArticleIdent: Q65241

 When viewing memory in byte format in a memory window in CodeView
 version 3.00 or 3.10, you cannot change the value of a byte in memory
 to the hexadecimal value 2E. The hex value 2E has an ASCII character
 equivalent of the period ("."). In CodeView, a period is used to
 display any nondisplayable character (for example, null, a carriage
 return, control characters, etc.), which means the period character
 can sometimes have special meaning to CodeView when it appears in a
 memory window.

 Because of the special usage of the period character in a memory
 window, CodeView does not allow periods to be typed directly into
 memory. In CodeView 3.00, attempts to change a byte value to 2E
 results in either the 2 or the E being entered and the other digit
 being ignored, depending on which value you enter first. In CodeView
 3.10, both the 2 and the E are returned to their original values once
 they have both been entered. If you move to the right side of the
 memory window where the ASCII equivalents are shown and you try to
 type in a period there, CodeView will also ignore that input.

 If you switch the memory window so that you are viewing memory in
 ASCII mode, actual periods can be typed in to any memory location.
 However, there is a problem with this because ALL other periods on the
 same line, which really represent various nondisplayable ASCII
 characters, are all converted to 2Es.

 If you use are viewing memory in a format other than bytes or ASCII,
 CodeView will allow a 2E to be entered. The workaround, then, if a
 period needs to be entered into memory, is to choose a different
 viewing mode other than ASCII or byte-mode, and then enter the period
 in the desired location as the value 2E. You can cycle through the
 available memory viewing modes by repeatedly pressing SHIFT+F3, or you
 can select the desired mode from the Memory Window option on the
 Options menu.

 Microsoft has confirmed this to be a problem in CodeView versions 3.00
 and 3.10. We are researching this problem and will post new
 information here as it becomes available.


 135. CV 3.00 Incorrectly Documents helpbuffer Switch as helpbuffers

 Product Version(s): 3.00   | 3.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | docerr
 Last Modified: 25-FEB-1991    ArticleIdent: Q63236

 In the "Configure CodeView" section of the online help for CodeView
 version 3.00, the "helpbuffer" switch is incorrectly listed as
 follows:

    helpbuffers:<size>

 This switch should be spelled as follows:

    helpbuffer:<size>

 CodeView will not recognize the first spelling. The correct spelling
 was incorporated into the online help beginning with CodeView version
 3.10.


 136. CodeView Crashes in DOS on "Drive Not Ready" Error

 Product Version(s): 3.00
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist3.00
 Last Modified: 25-JUL-1990    ArticleIdent: Q64026

 CodeView version 3.00 may hang after encountering a "Drive Not Ready"
 error. This error may occur if a file is opened on Drive A and a disk
 is not in the drive.

 To reproduce this problem, compile the following program with CodeView
 options (cl /Zi /Od):

    main () {
      FILE *fp;
      fp = fopen("a:\readme.doc","r");
    }

 If you run the program in CodeView version 3.00 without a disk in
 Drive A and press F5 to run the program, the following error will
 appear:

    Not ready reading drive A
    Abort, Retry, Fail?

 Regardless of what is typed, the machine will hang and you must do a
 cold reboot to remedy the crash.

 Note: CodeView versions 2.20 and 2.30 do not hang the machine if the
 above steps are executed. The fopen() just returns a NULL. OS/2 also
 handles the error correctly in versions 2.20, 2.30, and 3.00 of
 CodeView.

 Microsoft has confirmed this to be a problem with CodeView version
 3.00. We are researching this problem and will post new information
 here as it becomes available.


 137. CV1319 Error May Be Caused by CodeView DOS Extender

 Product Version(s): 3.00
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist3.00 fixlist3.10
 Last Modified: 31-AUG-1990    ArticleIdent: Q65242

 Real-mode CodeView (CV) version 3.00 (shipped with Microsoft C 6.00)
 may encounter problems on certain computers when extended memory is
 utilized for debugging programs. These problems involve the processing
 of interrupts while CodeView 3.00's internal DOS extender is being
 used to run CodeView in protected mode in conjunction with HIMEM.SYS,
 the extended memory (XMS) driver.

 The problems manifest themselves in various ways, due to both the
 varied interrupt handling speeds of different machines and the varied
 interactions of CodeView itself running in protected mode while the
 DOS program being debugged is still being run in real mode. The most
 common error is a protection violation, which shows up in CodeView as
 either a CV1319 error (internal error - unrecoverable fault) or as a
 system hang. The errors usually occur when you are paging through the
 code or manipulating the mouse.

 Registered Microsoft C 6.00 owners who are experiencing any of these
 problems with CodeView version 3.00 are encouraged to call Microsoft
 Technical Support at (206) 637-7096 to obtain information concerning a
 possible correction for these errors. However, there may be some cases
 where the only solution is to obtain a newer computer BIOS or to use
 CodeView without extended memory.
 Most reported problems have involved IBM PS/2 computers, but a number
 of these problems have also been reported on computers with an AMI
 BIOS. Note that CodeView version 3.10 includes modifications that are
 expected to eliminate most of these interrupt problems, but in some
 instances (especially with older AMI BIOS machines), an update of the
 BIOS may be the only solution.

 The easiest workaround to these protected-mode errors is to start
 CodeView without the use of extended memory. This can be done by
 removing the line in CONFIG.SYS that loads the HIMEM.SYS driver (and
 then rebooting the computer). Another option, if HIMEM is already
 loaded, is to start CodeView with the /D command-line option to
 specify explicitly that CodeView should use disk overlays, rather than
 extended or expanded memory. (Otherwise, if extended memory is
 available, CodeView will use the /X option by default.)

 Because these problems can occur only when CodeView is running in
 protected mode in extended memory, and because CodeView 3.00 requires
 HIMEM.SYS in order to run in protected mode, the problems are often
 mistakenly attributed to HIMEM.SYS. In reality, HIMEM.SYS is not
 responsible for the errors because it is just the memory manager that
 CodeView utilizes to get at extended memory. The errors are the result
 of an interrupt handling incompatibility between certain hardware
 configurations and the DOS extender built into CodeView.

 Microsoft has confirmed this to be a problem in CodeView version 3.00.
 This problem has been corrected in version 3.10.


 138. Label/Function Search Command Fails Under Codeview 3.00/3.10

 Product Version(s): 3.00 3.10 | 3.00 3.10
 Operating System:   MS-DOS    | OS/2
 Flags: ENDUSER | buglist3.00 buglist3.10
 Last Modified: 31-AUG-1990    ArticleIdent: Q65312

 Under CodeView versions 3.00 and 3.10, the Label/Function search
 command is described in the online help as performing a search of the
 current source window for an assembly-language label or function name.
 If the label is found, the debugger should switch from source to
 assembly mode to display a label in a library routine or assembly
 language module.

 In reality, this command fails with a message "Error - Unknown
 Symbol". The debugger does not switch into assembly mode. This problem
 can be reproduced by selecting Search from the CodeView menu, then
 selecting Label/Function and typing in "__chkstk" (without the
 quotation marks).

 Microsoft has confirmed this to be a problem with CodeView Versions
 3.00 and 3.10. We are researching this problem and will post new
 information here as it becomes available.


 139. Cannot Enable A20! with Orchid 386s

 Product Version(s): 3.00
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 17-DEC-1990    ArticleIdent: Q65360

 Using HIMEM.SYS version 2.50 with Orchid 386/25 motherboards with the
 caching controllers can cause the following error message:

    Cannot enable A20!

 Orchid Technology has verified that this is a problem with the PAL
 chip on these motherboards. Customers who are experiencing this
 problem should call Orchid Technology at (415) 683-0300 for an update
 of their PAL chip. Please have the revision of the motherboard on hand
 when calling.


 140. Mouse Cursor on Wrong Monitor During Dual-Monitor Debugging

 Product Version(s): 3.00 3.10
 Operating System:   MS-DOS
 Flags: ENDUSER | H_MOUSE
 Last Modified: 17-SEP-1990    ArticleIdent: Q65528

 Under certain conditions, when invoking real-mode CodeView (CV) in
 dual-monitor mode with /2, the mouse cursor appears on the wrong
 monitor. When this occurs, a "sprite" mouse cursor appears on the
 monitor that the application is to run on, while the secondary monitor
 where CodeView is running does not have a mouse cursor. Several
 workarounds to this problem are given below.

 The sprite mouse cursor is a "graphic" arrow cursor similar to that in
 Windows 3.00 or OS/2 Presentation Manager (PM), as opposed to the
 traditional "text" block cursor that usually appears when running
 CodeView or the Programmer's WorkBench (PWB).

 The problem of the mouse appearing on the wrong monitor occurs only on
 computers that have "extended register" video boards, such as some of
 the Video 7 VGA cards. Certain mouse drivers enable the sprite cursor
 when they detect these extended video registers. Because a monochrome
 monitor cannot support this extended mode mouse cursor, the cursor
 fails to switch to the secondary monitor when focus is switched to
 that monitor after CodeView is invoked with the /2 switch.

 The following are three possible workarounds to this problem:

 1. Upgrade to mouse driver version 7.04 or later. This version
    provides a new switch, /Y, which can be used with either the
    MOUSE.COM program or the MOUSE.SYS device driver. The /Y switch
    tells the mouse driver to disable the sprite cursor. The mouse
    driver update can be obtained free of charge by contacting
    Microsoft Product Support Services at (206) 637-7096.

 2. If a mouse driver earlier than version 7.04 is used, the problem
    may be worked around by creating a batch file or adding the
    following commands to the AUTOEXEC.BAT file:

       mode mono
       mouse
       mode co80

    These commands will switch focus to the monochrome monitor while
    the mouse is being invoked and then will switch the focus back to
    the color monitor. This method will prevent the mouse driver from
    detecting the extended registers and using the sprite cursor.

 3. Disable the extended video registers. Check the video card
    documentation to see if this method is possible with your
    particular card.


 141. CV May Come Up Only in Monochrome with 8514/A Display Adapter

 Product Version(s): 3.00 3.10
 Operating System:   MS-DOS
 Flags: ENDUSER | appnote SV0337.ARC B_QuickBas
 Last Modified: 16-OCT-1990    ArticleIdent: Q65701

 Real-mode CodeView (CV) may display only in monochrome (black and
 white) mode on some systems with an 8514 or color VGA monitor attached
 to an 8514/A display adapter. On these systems, the installation of an
 8514/A video card causes the BIOS video functions to return an
 incorrect value indicating that a monochrome VGA monitor is attached,
 rather than a color monitor.

 This same BIOS information contributes to the way in which these
 versions of CodeView (and various other programs) detect the type of
 video adapter present; thus, CodeView may incorrectly determine that
 it is running on a monochrome system and may display the screen only
 in black and white.

 Workaround
 ----------

 As a workaround, an application note titled "8514/A Monochrome to
 Color Patch" is available from Microsoft Product Support Services by
 calling (206) 637-7096. This application note contains a program,
 which may be run before CodeView is invoked and which will configure
 the BIOS information correctly for CodeView to come up in color.
 The program is also available in the Software/Data Library by querying
 on SV0337, the Q number of the article, or S12719. SV0337 was archived
 using the PKware file-conversion utility.

 This monochrome video problem is specific to DOS, and therefore, does
 not occur with protected-mode CodeView (CVP) under OS/2. However, the
 problem may appear if real-mode CodeView is run in the DOS
 compatibility box under OS/2. In addition, the problem may occur with
 other software, such as Microsoft QuickBASIC.

 With CodeView, another symptom of this problem is that the program
 output screen (which can be accessed by pressing F4) will usually
 appear as dark blue characters on a black background. This screen is
 essentially unreadable and remains this way even after CodeView is
 terminated. Typing MODE CO80 at the DOS prompt after exiting CV should
 restore the system to the default colors.

 Microsoft intends to change the video detection routine in future
 software releases in order to circumvent this problem. Although the
 problem is not specifically caused by CodeView, a more sophisticated
 video detection routine will determine what video adapter and monitor
 are present without relying on the possibly inaccurate BIOS data.


 142. CV /E Avoids Windows 3.00 386 Enhanced Mode Protection Error

 Product Version(s): 2.35 3.00 3.10
 Operating System:   MS-DOS
 Flags: ENDUSER | SR# S900919-57 B_QuickBas B_BasicCom W_Win3
 Last Modified: 24-OCT-1990    ArticleIdent: Q65934

 When you start Microsoft CodeView under Windows 3.00 in a 386 enhanced
 mode DOS box, the following error message is displayed:

    You have attempted to run protected-mode application under 386
    enhanced mode. To run the application, exit and run Windows using
    either the WIN /s or the WIN /r command.

 However, using WIN /s or /r is unnecessary. To avoid the error
 message, start CodeView with the /E option to tell CodeView that
 expanded memory is available, as follows:

    CV /E

 This information applies to Microsoft CodeView versions 2.35, 3.00,
 and 3.10 for MS-DOS.
 Note that 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 PDS version 6.00; and
 CodeView 3.10 is shipped with Microsoft BASIC PDS version 7.10.

 You may find that after the error message is generated, if you return
 to the DOS box and wait a few seconds, CodeView will start up. To
 avoid the error message, start CodeView as follows with the expanded
 memory (/E) switch (where <filename.exe> is the name of the program
 you want to debug):

    CV /E <filename.exe>

 To increase the size of programs that can be loaded into CodeView in
 conjunction with the /E switch, you can create a PIF file for CodeView
 and specify -1 for the Expanded Memory KB Limit, which instructs
 Windows to give the program all the EMS that it needs.

 CodeView will run without the above error message in a Windows 3.00
 DOS box in standard mode, WIN /S.


 143. CV1319 Error May Be Caused by Generic Breakpoints

 Product Version(s): 3.00   | 3.10
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified: 24-OCT-1990    ArticleIdent: Q66215

 In some situations a program will hang with the CodeView
 initialization error CV1319 even though the program runs correctly
 outside of CodeView. Deleting any generic breakpoints in the
 CURRENT.STS file may resolve this problem. The following is an
 example:

    [debug-]
          genericbp='E 0x47:0x0007

 The problem is that when you recompile your program, the code moves
 and the absolute breakpoint may now be set in the middle of a
 multibyte instruction rather than the beginning of the instruction.

 Additional Workaround
 ---------------------

 Invoke CodeView with the /TSF ("Toggle StateFileread") option. This
 option will either read or ignore the CURRENT.STS file based on what
 the statefileread switch is set to in the TOOLS.INI file.

 For example, if the statefileread switch is set to "yes" (the default)
 and CodeView is invoked with the /TSF option, the CURRENT.STS file
 will be ignored.


 144. Running Out of Memory in CodeView with /X

 Product Version(s): 3.00 3.10 3.11
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 24-OCT-1990    ArticleIdent: Q66230

 Under some circumstances, CodeView may still run out of memory while
 debugging large applications with the /X switch invoked to take
 advantage of extended memory with HIMEM.SYS. The debug information
 gets expanded when CodeView loads the program, so the following
 suggestions may help the problem:

 1. Don't use the quick compile (/qc) option. The symbolic information
    created by the quick compiler may expand much more when loaded by
    CodeView than the symbolic information created by the standard
    compiler. In addition, the quick compiler may create some duplicate
    debug references in the executable file. These duplicate references
    can take up significant memory when CodeView loads the program.

 2. Use the CVPACK utility, which is documented in the online
    documentation and on Page 21 of the "Microsoft C Reference" manual.
    CVPACK will compress the debug information in the file by removing
    duplicate references. Use the /P option to achieve maximum
    compression.


 145. CodeView Fails to Return Value in ES

 Product Version(s): 3.00 3.10 3.11
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist3.00 buglist3.10 buglist3.11
 Last Modified:  9-NOV-1990    ArticleIdent: Q66507

 When CodeView is running in extended memory and a call is made to
 interrupt 15h function C0h, the value in the ES register is not
 changed. This interrupt call should return the segment of the system
 configuration table in the ES register. If CodeView is run with the /D
 or /E option, a value is returned in the ES register as it should be.

 Microsoft has confirmed this to be a problem in CodeView versions
 3.00, 3.10, and 3.11. We are researching this problem and will post
 new information here as it becomes available.

 Sample Code
 -----------

 main ()
   {
    _asm mov ah, 0xC0
   _asm int 0x15
   }


 146. Memory Requirements for Real-Mode CodeView (CV.EXE)

 Product Version(s): 3.00 3.10 3.11 | 3.00 3.10 3.11
 Operating System:   MS-DOS         | OS/2
 Flags: ENDUSER |
 Last Modified: 11-NOV-1990    ArticleIdent: Q66513

 Real-mode versions of CodeView (CV) beginning with version 3.00 offer
 a number of ways to utilize available memory in order to make the
 greatest amount of conventional memory available to the program being
 debugged. The amount of memory actually used depends on the
 command-line options specified as well as the configuration of the
 system used for debugging.

 The following table shows the size of CodeView in standard DOS memory
 with each of the memory-specific command-line options (see the "More
 Information" section below for further details):

    Option  RAM Usage                   Option  RAM Usage
    ------  ---------                   ------  ---------

     /X       16K                       /D16     210K
     /E      192K                       /D32     225K
     /D      256K (same as /D64)        /D128    320K

 The following descriptions of the three memory-related CodeView
 options explain the ways in which each option affects memory
 utilization in addition to the respective amounts of conventional
 memory that CodeView requires with each. (This information pertains
 only to CodeView versions 3.00 and later -- versions of CodeView
 earlier than 3.00 require approximately 230K of RAM specifically for
 CodeView.)

 /X - Specifies that CodeView should utilize extended memory. Assuming
      that enough extended memory is available, this option moves both
      the symbolic information and most of CV itself into extended
      memory. Allowing CV to be loaded into high memory requires that
      approximately 16K to 19K of "control" code remain in conventional
      memory, thus all free conventional RAM over 19K is available to
      load the program to be debugged (the "debuggee").

 /E - Specifies that CodeView should utilize expanded memory. Assuming
      that enough expanded memory is available, this option moves both
      the symbolic information and CodeView's own overlays into
      expanded memory. The size of the CV "root" without the extra
      overlayed code is approximately 192K. Since the overlays do not
      cause any additional overhead with /E, all free conventional RAM
      over 192K is available to load the debuggee.

 /D - Specifies that CodeView should utilize disk overlays in
      conventional memory. By default, this option creates a 64K buffer
      area for loading disk overlays. With the 192K root, the 64K
      buffer means CV will take about 256K of conventional memory with
      /D. In addition, the symbolic information must also be loaded
      into conventional memory; therefore, since symbolic data varies
      with each program, it is not possible to specify the amount of
      memory available for the debuggee alone.

      The /D option can also be specified with a value that indicates
      the size of the overlay buffer area. This parameter can be any
      value from 16 to 128, which represents an overlay buffer size
      from 16K to 128K. Specifying /D16 will minimize CodeView's size
      with disk overlays to approximately 210K. This maximizes the
      amount of conventional memory that will be available to load the
      debuggee and the symbolic information. At the other extreme,
      /D128 causes CV to use approximately 320K of conventional RAM.
      This provides faster CodeView execution speed, but it will only
      work with smaller debuggees.

 Note: CodeView will default to the best memory usage possible. In
 other words, if NO memory usage option is specified, CV will try to
 use extended memory. If extended memory is unavailable, CV looks for
 expanded memory. CV will use disk overlays on its own only if expanded
 memory is not found.


 147. CV2206 Warning: Corrupt OMF Detected in <filename>

 Product Version(s): 2.x 3.00 3.10 | 2.x 3.00 3.10
 Operating System:   MS-DOS        | OS/2
 Flags: ENDUSER | S_MASM H_MASM
 Last Modified: 11-NOV-1990    ArticleIdent: Q66702

 When trying to debug a Macro Assembler program with CodeView, the
 following message may appear:

    CV2206 Warning: Corrupt debug OMF detected in <filename>,
       discarding source line information

 The error occurs when code segments are not of class "CODE". Page 104
 of the "Macro Assembler 5.10 Programmer's Guide" states the following:

    The CodeView debugger also expects code segments to have the class
    name 'CODE'. If you fail to assign a class type to a code segment,
    or if you give it a class type other than 'CODE', then labels may
    not be properly aligned for symbolic debugging.

 This is also mentioned in the "CodeView and Utilities" manual under
 section 1.3.8 titled "Preparing Assembly Programs."

 The following is an example of the problem:

 _text segment para public   ; 'CODE' should be added to this line

 begin    proc
       mov ah, 4ch
       int 21h
 begin    endp

 _text ends
       end begin


 148. How to Execute a Function From the Command or Watch Window

 Product Version(s): 2.x 3.00 3.10 3.11 | 2.x 3.00 3.10 3.11
 Operating System:   MS-DOS             | OS/2
 Flags: ENDUSER | docerr s_c 6.00 6.00a
 Last Modified:  4-DEC-1990    ArticleIdent: Q67007

 Page 201 of the "Advanced Programming Techniques" (APT) manual that
 accompanies Microsoft C versions 6.00 and 6.00a states that "any C
 function in your program (whether user-written or from the library)
 can be called from the Command window or the Watch window."

 This statement is not completely true. Actually, only functions
 compiled with full CodeView symbolic information can be called. This
 restriction eliminates all of the C run-time functions from being
 executed in this manner because they contain no symbolic information.
 A simple example of how to call a C run-time function is shown below.

 If an attempt is made to execute a function that has not been compiled
 with symbolic information via the Command window, the following error
 will be displayed in the Command window:

    CV1017 Error: Syntax error

 In CodeView versions 2.x, an "unknown symbol" error is displayed in
 the Command window.

 If an attempt is made to add the function to the Watch window via the
 Watch menu and the "Add Watch" command, CodeView will ignore the entry
 and beep. In versions 2.x, CodeView will give an "unknown symbol"
 error.

 The APT gives an example of calling a C function from the Command
 window via the following command:

    ?funcname (varlist)

 This command will only invoke the function and display its return
 value in the Command window. To add the function to the Watch window,
 a slightly different command must be used, as follows:

    w?funcname (varlist)

 The function name can also be added to the Watch window by choosing
 the Watch menu and the "Add Watch" command, and typing only the
 function name plus its variable list enclosed in parenthesis. Neither
 the "w" or the "?" are needed in this situation.

 It is important to note that you should be sure that the screen
 flip/swap option on the Options menu is turned on if the function you
 execute performs any screen input or output.

 For example, if you want to call a C run-time function or any other
 function that does not contain CodeView symbolic information, you must
 create a shell function that calls the desired function itself and
 gives the same return value.

 Therefore, if you wanted to call the C run-time function sqrt()
 directly from the CodeView Command window or Watch window, you would
 create a shell function that resembles the following:

 1. #include <math.h>
 2. double my_sqrt(double x)
 3. {
 4.    return(sqrt(x)) ;
 5. }

 You would then compile this function with CodeView information by
 compiling with the /Zi switch, and then link it into your program
 being sure to include /CO in your link command. Note that your program
 does not need to make a call to the function in order for it to be
 available for direct execution.

 To execute this function from the Command window, enter the following
 command:

    ?my_sqrt(4.0)

 The return value should be displayed on the next line in the Command
 window. In this example, 2.0000000000000 should be displayed as a
 result of the square root of 4.0.

 To add the function to the Watch window via the Command window, you
 would enter the following command:

    w?my_sqrt(4.0)

 The function could also be added to the watch window by choosing the
 "Add Watch" command from the Watch menu and entering the following at
 the Add Watch prompt:

    my_sqrt(4.0)

 When a function is added to the Watch window, that function is
 executed any time the Watch window is updated.

 Although these examples show a constant value as the parameter to the
 function, any variable that is in scope at the time could be entered
 as a parameter.


 149. Syntax Error When Watching Variables That Begin with "P"

 Product Version(s): 2.20 2.30 | 2.20 2.30
 Operating System:   MS-DOS    | OS/2
 Flags: ENDUSER | buglist2.10 buglist2.20 fixlist3.00
 Last Modified: 18-NOV-1990    ArticleIdent: Q67008

 When the following command is entered in the Command window to watch a
 variable that begins with the letter "p", the result is a syntax
 error:

 > W pvariable

 The syntax for watching a memory location is W[type] range, where the
 type and range specify the format and length of memory to be
 displayed, respectively.

 When no type is declared, as in the above example, the default type is
 used. The default type will be the last type used by a Dump, Enter,
 Watch Memory, or Tracepoint Memory command. If none of these commands
 has been used during the session, the default type is byte.

 The workaround for this problem is to explicitly declare a type in the
 watch statement, for example:

 > WB pvariable.

 Microsoft has confirmed this to be a problem in Microsoft CodeView
 versions 2.x. This problem has been corrected in Microsoft CodeView
 version 3.00.

 Additional keywords: buglist2.30 buglist2.35


 150. CV1017: Syntax Error Can Be Caused by a Leading Zero

 Product Version(s): 3.00 3.10 3.11 | 3.00 3.10 3.11
 Operating System:   MS-DOS         | OS/2
 Flags: ENDUSER |
 Last Modified:  4-JAN-1991    ArticleIdent: Q67160

 Since CodeView treats all values with a leading zero as octal numbers,
 the following error is reported when the value is not a valid octal
 number:

    CV1017: syntax error

 To enter a number in hexadecimal form, the value must be preceded with
 "0x" (without the quotation marks). If the value is a number in
 decimal form, any leading zeros should be dropped.

 You can also use the "0n" prefix to specify decimal numbers,
 independent of the current radix.


 151. CodeView Asks for Path to a Source File Without Extension

 Product Version(s): 2.x 3.00 3.10 3.11 3.50
 Operating System:   MS-DOS
 Flags: ENDUSER | s_lib s_utility
 Last Modified:  4-DEC-1990    ArticleIdent: Q67271

 If an old version of the LIB utility is used to store OBJ modules in a
 library, the extension may not be stored. This can cause a problem if
 a module is compiled with debug information and an .EXE is built for
 CodeView to debug. When CodeView attempts to open the source file for
 the module in the library, it will fail because there is no extension.
 It will then prompt you for the filename.

 This is a problem with the Microsoft LIB utilities earlier than version
 3.08 and some third-party library managers. Beginning with LIB version
 3.08, the full filename is stored in the library.


 152. CodeView Does Not Debug kbhit() Correctly

 Product Version(s): 3.00 3.10 3.11  | 3.00 3.10 3.11
 Operating System:   MS-DOS          | OS/2
 Flags: ENDUSER | buglist3.00 buglist3.10 buglist3.11
 Last Modified:  4-DEC-1990    ArticleIdent: Q67360

 When setting a breakpoint between the kbhit() function and a function
 to read a character from the input stream, CodeView will grab the
 character from the input stream when the breakpoint is executed.

 The following code example demonstrates the problem. If a breakpoint
 is placed on the line containing the getch() function, the character
 input from the keyboard will be placed in CodeView before the getch()
 function is actually stepped over. You will not be prompted for the
 character when you step over the getch() function. The character you
 typed to stop the kbhit() loop will be used for the getch() function
 call when that line is executed.

 Microsoft has confirmed this to be a problem in CodeView versions
 3.00, 3.10, and 3.11. We are researching this problem and will post
 new information as it becomes available.

 Sample Code
 -----------

 #include <stdio.h>
 #include <conio.h>

 void main(void)
 {
         int a;

         do {
                 printf(".");
         } while(!kbhit());

         a = getch();         // put breakpoint here

         printf("%c\n", a);
 }






 Microsoft Linker
 =============================================================================


 1. Corrupted Library Causes Error L1102

 Product Version(s): 3.61 3.64 3.65 | 5.01.20 5.01.21
 Operating System:   MS-DOS         | OS/2
 Flags: ENDUSER |
 Last Modified:  6-DEC-1988    ArticleIdent: Q38201

 The link error "L1102: unexpected end-of-file" is generated when the
 linker attempts to resolve externals in a corrupted or null-length
 library.

 This error most commonly occurs with a combined library, mlibx.lib,
 that is corrupted during the library creation stage of SETUP. Make
 sure to check the \LIB subdirectory for odd or null size libraries.
 Library rebuilding is needed if insufficiently-sized libraries are
 found.

 The L1102 error can also be generated if you inadvertently type in the
 name of a used library at the "list file" prompt, as follows:

    Run File  [SPUD.EXE]:      main.exe
    List File [NUL.MAP]:       libname.lib    (generates faulty library)
    Libraries [.LIB]:          libname.lib
    Definition File [NUL.DEF]: main.def

 This process creates a map listing with the specified library name in
 the current working directory. Because this directory is searched
 before the directory specified in the LIB environment variable, the
 incorrect library containing the map listing is used during linkage,
 causing the error L1102.


 2. /I Linker Option Should Read /INF

 Product Version(s): 3.61 3.65
 Operating System:   MS-DOS
 Flags: ENDUSER | docerr
 Last Modified: 18-OCT-1988    ArticleIdent: Q30515

 Pages 266 and 267 of the "Microsoft C Optimizing Compiler CodeView and
 Utilities" manual for Versions 5.00 and 5.10 incorrectly list the
 shortened name of the /INFORMATION option as /I.

 If /I is given as an option, the result is an error stating that /I is
 an unrecognized option.

 The correct shortened name for /INFORMATION is /INF.


 3. Maximum Libraries LINK Can Handle

 Product Version(s): 3.x 5.01.20 5.01.21
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 18-OCT-1988    ArticleIdent: Q31986

    LINK can handle no more than 32 libraries, i.e., on the LIBRARY
 prompt, you can specify up to 32 libraries.
    If you have more libraries, you have two choices: combine libraries
 or specify some of them at the object modules prompt. In the second
 case, LINK will treat the library as a collection of object modules,
 all of which should be included in your .EXE file.


 4. Maximum Number of Object Modules LINK Allows

 Product Version(s): 3.x 5.01.20 5.01.21
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 18-OCT-1988    ArticleIdent: Q31987

    There is no limit to the number of object modules LINK allows;
 however, LINK can operate only in certain limits imposed by the amount
 of available resources.


 5. The Meaning of an Invalid Object Module

 Product Version(s): 3.x 5.01.20 5.01.21
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 13-OCT-1988    ArticleIdent: Q31988

 An invalid object-module error message means that an object module
 does not conform to Microsoft object format. The description of object
 format can be found in "MS-DOS Encyclopedia Part E: Programming Tools
 Article 19: Object Module."


 6. Object Modules Handled by LINK

 Product Version(s): 3.x 5.01.20 5.01.21
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 15-JUL-1988    ArticleIdent: Q31989

    Successive versions of LINK always are backward compatible, but not
 necessarily upward compatible, i.e., the most recent versions should
 link any existing object module, but not necessarily any future object
 module.
    To solve this problem, update to the latest version of LINK.



 7. How LINK Orders and Combines Segments

 Product Version(s): 3.x 5.01.20 5.01.21
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 15-JUL-1988    ArticleIdent: Q31991

    Every segment belongs to a named class such as 'CODE', 'DATA', or
 'BSS'. LINK orders all segments with the same class name contiguously.
    Within each class, segments are placed in the same order as LINK
 encounters them. Segment classes are placed in the order they appear.
 If you do not give a class name when you define a segment in assembly,
 the segment gets the null class, which is treated like any other segment.
 If the /DOSSEG option is given, or one of the Microsoft language run-time
 libraries is used, LINK imposes the following additional order:

       code (class ending in 'CODE')
       far data (everything but DGROUP and 'CODE')
       DGROUP - the default data segment
           class 'BEGDATA' (special runtime segment)
           near initialized data (everything but 'BSS' and 'STACK')
           near BSS--uninitialized data  (class 'BSS')
           stack



 8. Link Error L1053 Symbol Table Overflow

 Product Version(s): 3.x 5.01.20 5.01.21
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 13-OCT-1988    ArticleIdent: Q31992

 Question:

 I am receiving link error L1053: symbol table overflow. What is the
 limit of the symbol table?

 Response:

 Under MS-DOS, this limit using the DOS-only linker (Versions
 3.x) is dependent on the amount of available memory in your computer.
 LINK can use all conventional memory available under DOS (up to 640K).

 Under OS/2, the segmented-executable linker (Versions 5.x and above)
 has no limit on the size of the symbol table because it extends the
 symbol table in virtual memory.


 9. Temporary Files Created at Link Time

 Product Version(s): 3.x 5.01.20 5.01.21
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 22-JUL-1988    ArticleIdent: Q31993

    The linker creates a temporary file when it runs out of memory to
 hold the symbol table or the load image and run-time relocations of
 the program being linked.



 10. How Overlays Are Set Up By the Linker

 Product Version(s): 3.x 4.06 4.07 5.01.20 5.01.21 5.03
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 26-JAN-1990    ArticleIdent: Q31994

 The overlay linker uses an interrupt to call in overlaid files. By
 default, the interrupt number used for passing control to overlays is
 63 (3f hex).

 The linker links the Microsoft overlay manager from the standard
 Microsoft language run-time libraries. The linker assigns segments to
 overlays based on the grouping you indicate. It replaces
 overlay-to-overlay far calls and root-to-overlay far calls with an
 interrupt sequence that calls the overlay manager. The overlay manager
 swaps overlays if necessary and returns control to the program.

 The linker replaces root-to-overlay and overlay-to-overlay far calls
 with the following sequence:

    INT     3Fh         ; can change # with /OVERLAYINTERRUPT:#
    DB      ?           ; target overlay segment number, where
                        ; every non-root code segment is numbered
                        ; starting at 1
    DW      ?           ; target offset within segment

 The interrupt handler is set to the overlay manager code that swaps
 out the resident overlay if necessary and swaps in the target overlay,
 then jumps to the target address. The overlay manager does nothing
 unusual in servicing the interrupts; it does not disable interrupts.
 However, it may issue INT 21h calls to swap overlays.

 The overlay manager assumes that once your initialization code has
 been executed, DS and SS will always be the same. Furthermore, it
 assumes you will initialize DS and SS to the value of DGROUP (the
 default data segment defined by Microsoft languages). Note that your
 program also must have a stack segment.

 A more detailed description of the overlay manager can be found on
 Page 715 of the "MS-DOS Encyclopedia," "Article 20: The Microsoft
 Object Linker."


 11. Why the First Module in the Code Segment Starts at Offset 16

 Product Version(s): 3.x 4.06 4.07 5.01.21 5.03 | 5.01.21 5.03
 Operating System:   MS-DOS                     | OS/2
 Flags: ENDUSER | s_c s_quickc s_quickasm h_masm h_fortran
 Last Modified: 14-FEB-1990    ArticleIdent: Q58688

 Question:

 Under some circumstances, I get 16 zero bytes at the beginning of my
 code segment. I'm linking with my own replacement C library with
 start-up code. The entry point to this start-up module is the first
 item in the module, and it always ends up at offset 16. Why is this?

 Response:

 The linker will insert 16 bytes at the beginning of the code segment
 if it determines that you are using standard segment naming
 conventions (/MS-DOSSEG) and the NULL segment is not explicitly
 removed (/NONULLSMS-DOSSEG). In your case, the linker assumes that you
 need support for signal() and allocates the first 16 bytes for it.

 Note: This will always be done for C programs by the compiler.


 12. Linker Outputs Information with Invalid Object Module

 Product Version(s): 3.x 5.01.20 5.01.21
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 15-JUL-1988    ArticleIdent: Q31999

    When an invalid object-module error message occurs, some
 information about the record and the position is printed.
    This information includes the object record type and the relative
 position of the record in the .OBJ file. There is little you can do
 with this information; it is mainly for compiler and assembler
 developers to point to the wrong object record.


 13. Incremental Linking

 Product Version(s): 3.x 5.01.20 5.01.21
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 15-JUL-1988    ArticleIdent: Q32000

    The following is a description of the incremental-linking process.
    Your file is built from a set of .OBJ files. Each .OBJ file is
 produced by the compiler or assembler from a source file. If a set of
 .OBJ files is large, then linking time can be long. If you change only
 one source file (i.e., in your set of .OBJ files you have one new .OBJ
 file), you can link all .OBJs one more time, or patch your .EXE file
 with the new .OBJ file. This patching is called incremental linking.
    Incremental linking only is supported for OS/2 and Windows
 programs.



 14. Explanation of a MAP File

 Product Version(s): 3.x 5.01.20 5.01.21
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 15-JUL-1988    ArticleIdent: Q32001

    A MAP file gives you a picture of how your code and data are
 arranged in memory when the program is loaded.
    First you get the list of segments in the order in which they will
 be loaded into memory. For each segment, you have its starting
 address, length, name, and class. Following the segments are groups,
 each specifying the starting address of the group.
    If you specify the /MAP switch and list filename, in the MAP you
 will get two lists of public symbols in your program. The first list
 will be sorted alphabetically, the second by addresses.
    If you specify the /LINENUMBERS switch, then in the MAP, you will
 get line numbers and the associated addresses of your source program.
 To produce line numbers in the MAP, give LINK an object file with
 line-number information. Use the /Zd option with any Microsoft
 compiler to include line numbers in the object file.
    Information from the MAP will help you debug your program and
 understand how the program is loaded into memory.


 15. L1087: "Unexpected End-of-File on Scratch File"

 Product Version(s): 3.x 5.x  | 5.10
 Operating System:   MS-DOS   | OS/2
 Flags: ENDUSER |
 Last Modified: 13-OCT-1988    ArticleIdent: Q34669

 The Link Utility generates the error message L1087: "unexpected
 end-of-file on scratch file" when a disk with the temporary linker
 output file has been removed. This information is documented in the
 "Microsoft Macro Assembler CodeView and Utilities Guide."

 The error message L1087 also can be caused by insufficient memory
 available on the disk that contains the temporary linker output file.
 The disk can be a hard disk, floppy disk, or RAM disk.


 16. Assigning Addresses to Overlay Segments

 Product Version(s): 3.x 5.01.20 5.01.21
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 15-JUL-1988    ArticleIdent: Q32003

    The linker assigns only code segments (identified by class names
 ending in "CODE") to overlays. Data segments go in the root. The
 particular overlay the segment goes in is determined by the module
 that first defines the segment.

    Note that the linker assigns segments, not object modules, to
 overlays. Therefore, if you have the following command

     LINK A+(B+C)

 where

     A   defines public SEG1
     B   defines public SEG2
     C   defines public SEG1

 then C's contribution to SEG1 goes in the root, not in the first
 overlay, because SEG1 was first defined in a root module.
    The linker orders all segments as it normally would, ignoring the
 overlays and using the class and combine-type rules described
 elsewhere. The linker then assigns addresses for every segment in the
 root up to the first overlay segment. Before the first overlay
 segment, it defines a special empty segment called OVERLAY_AREA. Then
 for each overlay it assigns addresses for every segment in the overlay
 so that the first segment in the overlay starts at OVERLAY_AREA. One
 particular overlay will end at a higher address than all the others;
 at this address, the linker defines a special empty segment called
 OVERLAY_END. Finally, the linker assigns addresses for all remaining
 segments in the root so that the first one starts at OVERLAY_END. The
 load image looks like the following:

         ------------+-> 0000
         |           |
         |  root     |
         |           |
         +-----------+-> OVERLAY_AREA
         |  overlay  |
         |  area     |
         |           |
         +-----------+-> OVERLAY_END
         |  root     |
         +-----------+

    The resultant MAP file has some different contents than the
 pre-overlay file. All items listed are declared as "res", meaning
 resident. The items contained within the overlay modules are also
 declared as "res".
    At the top of the MAP file, the segments are listed in the exact
 order in which they will be in the load image, and each segment is
 identified as being in a particular overlay or the root.
    Every symbol marked "res" is in a root segment and every symbol
 marked "ovl" is in an overlay segment. If symbols are not where you
 think they ought to be, remember the linker assigns segments, not
 modules, to overlays.
    For more information on overlays, refer to the 1988 "MS-DOS
 Encyclopedia."


 17. Link Error L1089

 Product Version(s): 3.51 3.55 3.60 3.61 3.64 3.65 5.01.20 5.01.21
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 22-JUL-1988    ArticleIdent: Q32829

    If you are receiving the following error message, check to see if
 the TMP environment variable is set correctly:

    L1089   'filename' : cannot open response file

   If the TMP variable is not set, temporary files cannot be created
 and this error may occur.



 18. Cannot Overlay Small-Model Code

 Product Version(s): 3.60 3.61 3.64 3.65 5.01.20 5.01.21
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 12-OCT-1988    ArticleIdent: Q34294

 Problem:

 I have specified overlays for my small-model code, but the link map
 shows that no overlays are produced.

 Response:

 You cannot overlay small-model code. You must change the memory model
 to medium, large, or huge. Page 285 of the "Microsoft CodeView
 Utilities" manual that comes with C Versions 5.00 and 5.10, MASM
 Versions 5.00 and 5.10, and Pascal Version 4.00, and Page 135 of the
 "Microsoft FORTRAN Optimizing Compiler User's Guide" states that you
 can overlay only modules to which control is transferred and returned
 by a standard 8086 long (32-bit) call/return instruction.


 19. Link Error 4051

 Product Version(s): 3.60 3.61 3.64 3.65 5.01.20 5.01.21
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 22-JUL-1988    ArticleIdent: Q32831

    If you receive link error 4051, check the following:

    1. Is the LIB environment variable set correctly? Check
       for spaces around the equal sign or any extra characters
       at the end of the line.
    2. Which version of the linker is being used? Old versions of
       the linker do not recognize the LIB environment variable.
          Make sure the linker being used is the one that came with
       the product.
    3. Are the library names being asked for component libraries or
       combined libraries? Libraries compiled under C Version 4.00 or
       earlier have component library names embedded in the .OBJ files.
       With later versions of the C compiler, combined libraries are used
       and the component libraries will not be found.
          This behavior also exist when upgrading from Pascal Versions 3.32
       or earlier to Pascal Versions 4.00 or greater.
          The work-around for this behavior is to recompile all .OBJ file
      (and libraries) with the new compiler or to use the /NOD switch
      when linking, and specify all the libraries (combined and otherwise)
      to be used. The following is an example:

             link /NOD  test,,,llibce.lib;

    4. Is the correct library available for the math option chosen?
    FORTRAN defaults to the co-processor library (e.g. LLIBFOR7.LIB).
    C and Pascal default to the emulator math library (e.g. SLIBCE.LIB
    and LIBPASE.LIB)



 20. LINK /CO /DO in OS/2 Gives Protection Violation

 Product Version(s): 5.01.21 | 5.01.21
 Operating System:   MS-DOS  | OS/2
 Flags: ENDUSER | buglist5.01.21
 Last Modified: 13-OCT-1988    ArticleIdent: Q34374

 The Microsoft Segmented Link Utility Version 5.01.21 will
 incorrectly generate a protection violation under OS/2 when the
 command line uses the options /CO /DO, respectively.

 OS/2 gives the message SYS1943: "A program caused a protection
 violation." The SYS1811 violation follows, indicating the process has
 stopped.

 The work around for this problem is to order the switches differently.
 Instead of including /CO /DO in the command line, the command line can
 be reorder to /DO /CO.

 Microsoft has confirmed this to be a problem in Version 5.01.21. We are
 researching this problem and will post new information as it becomes
 available.


 21. /NOE Option for Redefinition Error L2044

 Product Version(s): 3.x 5.x | 5.10
 Operating System:   MS-DOS  | OS/2
 Flags: ENDUSER |
 Last Modified: 13-OCT-1988    ArticleIdent: Q34502

 The /NOEXTDICTIONARY switch tells the linker NOT to take advantage of
 additional information recorded in Extended Dictionary in the library
 file. This additional information describes which module in the library
 calls any other module from the same library, saving linker number
 of passes through the library file to pick up all required modules.

 If you have a call in your code to the library function FOO and FOO
 calls another function BAR from the same library, then at processing
 time of FOO, the linker will pull out BAR. This process occurs because
 the extended dictionary has a link between FOO and BAR.

 Linking without /NOE causes the following error if you want to pull
 FOO in from the library but you want to provide its own BAR:

 L2044 BAR : symbol multiply defined, use /NOE

 This error resulted from the linker pulling FOO and BAR from the
 same library, then later it sees BAR coming from user .OBJ file.

 Using /NOE in this case prevents the linker from pulling out
 BAR from the library, so your BAR routine is used instead.

 If you have genuine symbol redefinition, then when linking with /NOE
 you will see the following error:

 L2025 BAR : symbol defined more than once


 22. L2001 Fixups without Data

 Product Version(s): 3.65 5.01.21 | 5.01.21
 Operating System:   MS-DOS       | OS/2
 Flags: ENDUSER |
 Last Modified: 12-OCT-1988    ArticleIdent: Q35155

 The Link Utility can generate the linker error message L2001:
 fixup(s) without data. In the manual, the linker error is described
 as follows:

 A FIXUPP record occurred without a data record immediately
 preceding it. This is probably a compiler error. (See
 the "Microsoft MS-DOS Programmer's Reference" for more information
 on FIXUPP.

 In most cases, the error message is generated from an
 assembly-language program that doesn't make sense from the linker's
 point of view, but is convenient for users. The following is an
 example:

     extrn   foo:word

     ABSEG   segment at 123          ; absolute segment

     dw      offset DGROUP:foo       ; offset portion of address of "foo"

     ABSEG   ends

 This tells the linker to fix up a location in ABSEG with the address
 of foo. But ABSEG is an absolute segment and has no data to be fixed
 up.

 Another example is when you include the same STRUC definitions in both
 absolute and non-absolute segments, so that the STRUC definitions
 contain relocatable addresses.



 23. Setting the Overlay Interrupt (/O) in LINK

 Product Version(s): 3.61 3.65
 Operating System:   MS-DOS
 Flags: ENDUSER | docerr
 Last Modified: 20-JAN-1989    ArticleIdent: Q40408

 Question:

 Page 272, Section 12.2.12, of the "Microsoft CodeView and Utilities
 Software Development Tools for the MS-DOS Operating System" manual
 states that you can change the default overlay interrupt. The default
 interrupt is 3F hexadecimal. Is the manual correct? Do you have to
 change the interrupt if you have a program that uses overlays and it
 spawns a program that also uses overlays?

 Doesn't the compiler save interrupts? Suppose both Programs A and B
 use overlays and A spawns B. If B is a Microsoft C Version 5.00 or
 5.10 program, shouldn't it restore the original INT 3F address when it
 exits? Thus, everything should work correctly without
 /OVERLAYINTERRUPT.

 Response:

 You are correct; the C Versions 5.00 and 5.10 compiler saves and
 restores the interrupt so there should be no conflict. The C Versions
 5.00 and C 5.10 manual is incorrect. This switch need only be used if
 you are linking a program with overlays, and INT 3F is being used by
 something else when you run the program. For example, INT 3F might be
 used to communicate with a hardware board or a TSR might use it;
 however, this is unlikely.

 This option is for advanced users who know their configurations well
 enough to know who is using which interrupt vectors and know there is
 a conflict.


 24. LINK Environment Variable Ignored When Linking Through CL

 Product Version(s): 5.00 5.10 | 5.10
 Operating System:   MS-DOS    | OS/2
 Flags: ENDUSER | S_C S_QuickC
 Last Modified: 15-AUG-1989    ArticleIdent: Q47503

 Problem:

 To increase the size of my stack, when I set an environment variable
 called LINK equal to /ST:4096, it doesn't work correctly when I link
 using CL.

 Response:

 Before CL spawns the linker, it clears the environment of all
 variables except LIB. Consequently, the LINK environment variable
 doesn't exist when the linker is invoked, and any options that were
 specified by it are not seen. When linking with CL, any desired linker
 options should be specified on the CL command line after the /link
 switch.

 The same behavior is seen with the command line compilers from QuickC
 Version 1.00 and 1.01, but not with QuickC 2.00 or QuickAssembler.


 25. Why Unitialized Global Variables Don't Appear in C 5.10

 Product Version(s): 3.65
 Operating System:   MS-DOS
 Flags: ENDUSER | SR# G881021-5044
 Last Modified:  6-DEC-1988    ArticleIdent: Q38725

 Questions:

 Why don't uninitialized global variables show up in the library
 listing when the module containing them has been placed in the
 library? It appears that the librarian does not "see" uninitialized
 global variables.

 If my main program declares an extern, and an .OBJ with which its
 linked declares it globally (without extern), but doesn't initialize
 it, the symbol appears in the link map and space is allocated for it
 in the .EXE. This behavior seems different from previous versions of
 the compiler. If the .OBJ file is placed as a library rather than
 linked explicitly, the symbol does not appear in the .EXE. Why does it
 behave differently?

 Response:

 In Version 5.00 of the C Compiler, we introduced a new concept into
 our linking process called "communal data." Communal data can be
 declared in many modules, but only one copy of the data will exist
 in the linked .EXE file. (It is similar to the concept of COMMON
 blocks in FORTRAN.)

 In C, data declared outside of a function without a storage class is
 now considered to be communal data. (This is a change from previous
 versions.) Communal data declarations generate no definitions, just
 declarations; whereas initialized, or global, data declarations
 generate both definitions and declarations.

 Communal declarations may refer to a global definition. If they do,
 the linker simply adjusts the address as necessary. However, if
 there is no global definition of the variable, the linker combines
 the declarations into one definition and allocates the appropriate
 amount of space. For example, it is legal to declare

    int x;

 in several different modules without a corresponding

    int x = 0;

 Communal declarations are NOT copied into libraries. (This is
 documented on Page 84 of the "Microsoft C Language Reference Manual.")
 If you want the variable to appear in a library, it MUST be
 initialized so that it is global rather than communal. Communal
 variables are not included in libraries because they can cause
 strange conflicts. For example, let's suppose you
 unwittingly used a variable name that was also the name of a communal
 variable in your library. At link time, the linker would allocate
 only ONE copy of that variable without generating any warning.

 The symptom would be that your variable would mysteriously change
 every time you called the library function that used the communal
 variable. This problem would be a very difficult to trace.

 Now that we understand communal variables and how they interact with
 libraries, we can answer your questions.

 The first question was basically, "Why don't my communal variables
 show up in the library listing?" Because communal data is not placed
 into the library, it won't show up in the listing.

 The second question was, "How come the communal variable shows up in
 the .EXE file if I link it from an .OBJ file but not from a .LIB
 file?" It shows up from the .OBJ file because the communal variable
 is allocated space by the linker if it doesn't resolve to a global
 definition. It does NOT appear in the link produced by the .LIB file
 because it does not appear in the library dictionary.

 Note: this behavior is the result of doing something we ask you not to
 do; namely, putting communal data in a library. Data intended to be
 placed in a library must be initialized.


 26. Example of Using a Response File with LINK

 Product Version(s): 3.65   | 5.01.20
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified: 20-JAN-1989    ArticleIdent: Q40429

 The following is a small example of using a response file with LINK.

 A response file contains responses to the LINK prompts. The responses
 must be in the same order as the LINK prompts.

 LINK treats the input from the response file just as if you had
 entered it in response to prompts or in a command line. It treats any
 carriage-return-linefeed combination in the response file the same as
 if you had pressed the ENTER key in response to a prompt or included a
 comma in a command line.

 Note: You cannot put comments in response files.

 The following is an example of a file named RESPONSE.ONE:

 file1 file2 file3 file4
 /pause /map
 filelist
 graphics.lib

 Type the following at the command line:

    LINK @response.one


 27. Error L2025: Symbol Defined More than Once

 Product Version(s): 5.10   | 5.10
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified: 20-JAN-1989    ArticleIdent: Q40485

 Problem:

 I cannot link a function name in my object file with a library
 containing that same function name and have the resulting EXE call my
 function and not the library's.

 I am using /NOE; however, I receive the following error:

 (...): error L2025: (my function name) : symbol defined more than once
  pos: (some number) Record type: 53E8

 Response:

 You can only perform this task if the function name is an individual
 module. The following procedure demonstrates the error:

 1. Create a file CALL.C that calls functions A() and B().

 2. Create functions A() and B() in fileA.c and fileB.c, and compile
    them to objects.

 3. Do the following to create TEST.LIB:

       LIB TEST +fileA +fileB, test.lst

 4. Change B() in fileB.c and compile the following:

       cl call.c fileB.c test.lib /link /NOE /INF

    You will have an EXE that calls A() from the library and B() from
    your modified fileB.c.

 5. Combine fileA.c and fileB.c into one file called TEST.C.

 6. Compile to object code.

 7. Delete the old TEST.LIB, and do the following:

       LIB TEST +test, test.lst

    (Normally you would change fileB.c, but this is not necessary here.)

       cl call.c fileB.c test.lib /link /NOE /INF

 You will receive the following error:

 TEST.LIB(test.c) : error L2025: _B : symbol defined more than once
  pos: 13E Record type: 53E8
 There was 1 error detected

 When you encounter this error, it is usually because the function you
 are trying to overwrite is part of a set appearing in one module.

 The library listing looks as follows in the first case:

 _A................fileA             _B................fileB

 fileA             Offset: 00000010H  Code and data size: 95H
   _A

 fileB             Offset: 000002a0H  Code and data size: 92H
   _B

 You will be able to replace A() or B(). The listing in the
 second example looks as follows:

 _A................test              _B................test

 test              Offset: 00000010H  Code and data size: deH
   _A                _B

 You will not be able to replace either A() or B() without removing the
 TEST module with the LIB utility. You may have to provide replacements
 for both functions and not just the one you want to change. For more
 information, query on the following words in this KnowledgeBase:

    L2029 unresolved externals


 28. Default for NODATA When Using the _export Keyword

 Product Version(s): 5.01.21 | 5.01.21
 Operating System:   MS-DOS  | OS/2
 Flags: ENDUSER | buglist5.10.21 buglist5.02 fixlist5.03
 Last Modified: 21-AUG-1989    ArticleIdent: Q47826

 Question:

 What is the default for NODATA when using the _export keyword? The
 _export keyword is used to mark functions in DLLs for export. It
 appears that for real-mode windows, for normal applications, _export
 does not use NODATA. However, for DLLs (also for real-mode windows)
 _export marks the function NODATA. How does the keyword _export mark
 functions (NODATA or not).

 Response:

 The default as issued by the compiler is not NODATA, i.e., the
 exported routine is assumed to use the shared data segment.
 Unfortunately, the linker has a problem that causes it to mistakenly
 assume NODATA for all exports declared from the .OBJ file.

 Microsoft has confirmed this to be a problem with LINK Version 5.01.21
 and 5.02. The problem was corrected in LINK Version 5.03 and later.

 In OS/2 this should not make any difference. In Windows, the program
 loader looks for the -Gw sequence in the prolog of the exported entry
 and replaces it with a sequence to load DS. The _loadds keyword will
 generate the load-DS sequence in the first place.

 In any case, a workaround is to not use the _export keyword and
 declare the routine in EXPORTS in the .DEF file.


 29. No Default Extension for a Linker Response File

 Product Version(s): 3.55 3.60 3.61 3.64 3.65  | 5.01.21 5.01.21
 Operating System:   MS-DOS                    | OS/2
 Flags: ENDUSER |
 Last Modified:  2-MAR-1989    ArticleIdent: Q41611

 The Microsoft Overlay Linker does not have a default extension for a
 response file; unlike Phoenix's PLINK, which uses a default .LNK
 extension.

 This information also applies to the Microsoft Segmented-Executable
 Linker.


 30. Ambiguous Switch /PAC with QuickC 2.00 Linker

 Product Version(s): 4.06
 Operating System:   MS-DOS
 Flags: ENDUSER | s_quickc b_quickbas docerr
 Last Modified: 22-JAN-1990    ArticleIdent: Q42027

 Using the /PAC switch with LINK Version 4.06 results in the
 following error:

    fatal error L1001: PAC : option name ambiguous

 This same option works correctly on Versions 3.65 and 5.01.21, and is
 documented as being a valid shorthand name for /PACKCODE on Page 131
 of the "QuickC Tool Kit."

 The problem is due to a conflict with an option that is not documented
 in the Tool Kit, but is displayed when LINK is invoked with /HELP. The
 option that causes the ambiguity is /PACKDATA, which causes data
 segments to be combined.

 The shortest version of /PACKCODE that can be used is /PACKC.
 Similarly, /PACKD is the shortest version of /PACKDATA that can be
 used.


 31. /CO before /DO Causes Problems in LINK

 Product Version(s): 3.65 4.06 5.01
 Operating System:   MS-DOS
 Flags: ENDUSER | h_masm s_pascal h_fortran buglist3.65 buglist5.01
 Last Modified: 28-MAR-1989    ArticleIdent: Q42212

 When compiling or assembling with the /Zi switch to include CodeView
 symbolic information and linking with /CO to preserve it, the
 placement of the /DO switch is crucial. If the /CO switch is specified
 before /DO, the following behavior may occur when running CodeView:

    Message                                Behavior

    Enter directory for  (cr for none)?    When CodeView is executed,
                                           no source code will appear.

    Unable to open file

    Internal debugger error: 13            When attempting to change
                                           from assembly view to source
                                           CodeView. Hanging of the
                                           machine when executing
                                           CodeView.

 If switching the order of the /CO and the /DO switches does not
 take care of the problem then you have to put the .DOSSEG into
 your MASM routines and not use the /DO switch.

 Microsoft has confirmed this to be a problem in Versions 3.65 and
 5.01. We are researching this problem and will post new information as
 it becomes available.

 While LINK Version 5.01 may be used in OS/2, the /DO switch has no
 meaning. Using it, however, causes the linker to GP fault if /CO
 precedes /DO.



 32. Unimplemented Switch /BI with QuickC 2.00 Linker

 Product Version(s): 4.06
 Operating System:   MS-DOS
 Flags: ENDUSER | S_QUICKC
 Last Modified: 24-JAN-1990    ArticleIdent: Q42849

 The /BINARY switch for Link Version 4.06 is documented on Page 122 of
 the "Microsoft QuickC Tool Kit" as a switch used to create .COM files
 for assembly-language programs. Its shorthand version is /BI. This
 switch is an alternative to creating .EXE files and then running them
 through EXE2BIN.

 This switch is currently not implemented, a fact documented in the
 README.DOC on line 665, "Creating a .COM file." Using it will result
 in the following error:

     fatal error L1002: BINARY : unrecognized option name


 33. How /NOE (No Extended Dictionary) Is Used by the Linker

 Product Version(s): 3.65 4.06 5.01 | 5.01
 Operating System:   MS-DOS         | OS/2
 Flags: ENDUSER | S_C H_FORTRAN S_QUICKC
 Last Modified:  6-APR-1989    ArticleIdent: Q43009

 This article contains information about the LINK option /NOE and how
 it relates to the three following topics:

 1. The Extended Dictionary and how LINK uses it

 2. The definition of genuine redefinition

 3. Why redefinitions are not detected in some situations

 The LINK option /NOE stands for No Extended Dictionary.

 What is the extended dictionary and how does LINK use it? How does
 LINK use the extended dictionary?

 LINK uses the extended dictionary to speed up library searching. For
 example, if the library module A calls functions in module B and
 module C, the extended dictionary tells LINK that, if your program
 requires module A from library, it will also require modules B and C.
 According to this information, LINK pulls in the three modules A, B,
 and C all at once. This way, LINK doesn't have to search the library a
 second time to resolve references from module A to modules B and C.

 What is a genuine redefinition?

 The ERRMSG.DOC file states that when linker error L2044 occurs, the
 /NOE switch should be used. When linker error L2025 occurs, the
 program has a genuine redefinition problem.

 A genuine redefinition is any redefinition that has nothing to do with
 the extended dictionary. A redefinition error that occurs when you
 specify the /NOE switch indicates a genuine redefinition, as in the
 following example:

     FOO.OBJ:
         defines "_foo"
         calls "_libfunc"

     Module A: (in XYZ.LIB):
         defines "_libfunc"
         defines "_foo"

 If you run "LINK foo /NOE,,,xyz.lib", the L2025 error will be produced
 because module A is pulled in and redefines the symbol "_foo".

 When LINK encounters the redefinition while processing a library
 module, it assumes that the error might go away if you were to add the
 /NOE switch. This would be true if the symbols were defined like this
 as follows:

     FOO.OBJ:
         defines "_foo"
         calls "_libfunc"

     Module A (in XYZ.LIB):
         defines "_libfunc"
         calls "_foo"

     Module B ( in XYZ.LIB ):
         defines "_foo"

 The extended dictionary tells LINK to link modules A and B, even
 though module B should not be linked because "_foo" is already
 defined. In this case, the /NOE switch will eliminate the error.

 LINK cannot figure out when the error is due to the extended
 dictionary and when it is not; therefore, it assumes that the extended
 dictionary will cause a redefinition error when processing a library
 module.

 Please note that redefinitions not detected in some situations. For
 example, when the function 'printf' is redefined in a program module
 and the module is linked with SLIBCER.LIB without using the /NOE
 switch, LINK does not complain about the redefinition at all. LINK
 does not detect a redefinition because the module that defines printf
 in the library is not pulled in; thus, there is no redefinition.

 If your program module redefines a library function that is also
 called by other library functions used by your program, you will get a
 redefinition error. The extended dictionary specifies which library
 modules call routines in other library modules. Consider a
 "second-level" function to be any library function called by a library
 function in another module. For example, spawnve and _setargv are
 second-level functions because they are called by other library
 functions; printf is not. You can get a redefinition error only if you
 redefine a second-level library function called by some first-level
 routine being linked into your program.


 34. Producing an _TEXT Segment for Multiple Object Modules

 Product Version(s): 3.x 4.06 | 5.01.20 5.01.21
 Operating System:   MS-DOS   | OS/2
 Flags: ENDUSER | S_C
 Last Modified:  6-APR-1989    ArticleIdent: Q43128

 In a map file, a <modulename>_TEXT will be produced for each logical
 code segment in your program. Since small and compact model programs
 have only one code segment, you only get one logical segment, _TEXT.
 Medium- and large-model programs, however, will have a separate
 logical segment for each object module in the program, and thus produce
 a <modulename>_TEXT for each logical segment.

 To generate a map file, use the /M option with LINK or the /Fm option
 with CL.

 The following is an example map file generated when compiling a
 program with two object modules in small-memory model:

  Start  Stop   Length Name                   Class
  00000H 016EAH 016EBH _TEXT                  CODE
  ...

 The following is an example map file generated when compiling the same
 program with two object modules in large-memory model:

  Start  Stop   Length Name                   Class
  00000H 0000DH 0000EH MAPL_TEXT              CODE
  0000EH 00023H 00016H MAP2_TEXT              CODE
  00024H 01B2CH 01B09H _TEXT                  CODE
  ...

 MAPL_TEXT and MAP2_TEXT come from the files MAPL.OBJ and MAP2.OBJ,
 respectively. The _TEXT is the Microsoft run-time library and any
 third-party libraries.



 35. LINK: Renaming Overlayed Executables Will Cause Problems

 Product Version(s): 5.01.21
 Operating System:   DOS
 Flags: ENDUSER | s_C s_Pascal h_FORTRAN
 Last Modified:  6-APR-1989    ArticleIdent: Q43139

 When the Microsoft linker creates an executable file with overlays,
 the name of that EXE is hard coded into the file for use by the overlay
 manager. The Microsoft linker only creates internal overlays, i.e.,
 rather than producing FOO.EXE, FOO1.OVL, and FOO2.OVL, the two
 overlays are contained in FOO.EXE.

 If the executable is renamed at any point after linking, the overlay
 manager will still use the hard-coded name found in the EXE to locate
 the overlays, and will fail with the following prompt:

    Cannot find <oldname>
    Please enter new program spec:

 In order to change the name of the executable without receiving this
 error, it must be relinked and given the new name at that time.


 36. LINK: Creating and Accessing _edata and _end

 Product Version(s): 3.X 4.06 | 5.01.20 5.01.21
 Operating System:   MS-DOS   | OS/2
 Flags: ENDUSER | s_c
 Last Modified:  6-APR-1989    ArticleIdent: Q43165

 LINK creates the two symbols _edata and _end when the LINK option
 /DOSSEG is used. If a program is compiled by a Microsoft high-level
 language compiler, or if an assembly program written in Microsoft MASM
 uses .DOSSEG directive, LINK uses this option automatically.

 LINK gives _edata the address of the beginning of BSS segment and
 gives _end the address of the end of BSS segment. Since the STACK
 segment is directly above the BSS segment, the address of _end also
 marks the lowest address of the STACK segment.

 To obtain the addresses for these two symbols, declare the following
 in your C program:

 unsigned char edata, end ;

 The addresses, &edata and &end, can now be used to locate _BSS and
 STACK. They can also be examined in CodeView. Modifying these two
 variables is not recommended.

 Note: The segment BSS referred to in this article actually includes
 the segment C_COMMON. However in a map file created by LINK, BSS and
 C_COMMON are listed as two separate segments.



 37. Linker Options /PADDATA and /PADCODE

 Product Version(s): 4.06
 Operating System:   MS-DOS
 Flags: ENDUSER | S_QuickC docerr
 Last Modified: 18-SEP-1989    ArticleIdent: Q44928

 Question:

 I ran the linker Version 4.06 that comes with the Microsoft QuickC
 Compiler Version 2.00 with the /help option as follows:

    LINK /HELP

 I noticed two switches for which I couldn't find documentation:
 /PADDATA and /PADCODE. What are these options for?

 Response:

 The /PADC[ODE]:padsize option causes LINK to add filler bytes to the
 end of each code module. The option is followed by a colon and the
 number of bytes to add. (Decimal radix is assumed, but you can specify
 special octal or hexadecimal numbers by using a C-language prefix.)
 Thus, the following adds an additional 256 bytes to each code module:

    /PADCODE:256

 The default size for code-module padding is 0 bytes.

 The /PADD[ATA]:padsize option performs a function similar to
 /PADCODE, except that it specifies padding for data segments (or data
 modules, if the program uses small or medium-memory models). Thus,
 the following adds an additional 32 bytes to each data module:

    /PADDATA:32

 The default size for data-segment padding is 16 bytes. Note that if
 you specify too large a value for padsize, you may exceed the 64K
 limitation on the size of the default data segment.

 These two options are quite useful when used in conjunction with
 QuickC Version 2.00's incremental linking option. Using them correctly
 increases the incremental linking speed of a program.

 These two options are documented on Page 64 in the update section of
 the Microsoft C Optimizing Compiler Version 5.10 "CodeView and
 Utilities, Microsoft Editor, Mixed-Language Programming Guide" manual.


 38. Linker Error L2013 May Be a Result of a Problem in MASM 5.10

 Product Version(s): 3.x 4.06 4.07 5.01.21 5.02 5.03 5.05
 Operating System:   MS-DOS
 Flags: ENDUSER | h_masm
 Last Modified: 27-DEC-1990    ArticleIdent: Q59894

 The error message for linker error L2013 is as follows:

    error L2013 LIDATA record too large
       pos: xxx Record type: 743C

 In the README.DOC file that comes with MASM version 5.10, Microsoft C
 version 5.10, and the "Microsoft FORTRAN CodeView and Utilities User's
 Guide" version 5.00 manual, the recommended course of action is to
 call Microsoft Product Support at (206) 637-7096.

 The error is a result of an invalid object module. This is a known
 problem in MASM 5.10. The most likely cause is a duplication of some
 large data item, such as a structure.

 The easiest workaround is to break up the duplication(s) into smaller
 parts.


 39. LINK 5.02 Should Not Be Used with ILINK 1.10

 Product Version(s): 5.02
 Operating System:   MS-DOS
 Flags: ENDUSER | S_QuickC
 Last Modified: 30-AUG-1989    ArticleIdent: Q45536

 LINK Version 5.02, which comes as a secondary linker for QuickC 2.00,
 should not be used with ILINK Version 1.10, which also comes with
 QuickC 2.00.

 Inside the QuickC environment, this combination has caused problems
 with floating point-values being printed with printf. Outside of the
 environment, the same executable results in math error M6104.

 The source code below prints "FP = 0.00000" instead of "FP =
 5.020000". Running from the DOS prompt, in this case, produces the
 same results.

 Source Code
 -----------

     #include <stdio.h>

     void main( void )
     {
         float fp = 5.02F;

         printf( "FP = %f\n", fp );
     }

 LINK Version 4.06 should be used if ILINK is also to be used. If it is
 necessary to use Version 5.02 of the linker, incremental linking
 should be disabled from within the environment.

 Microsoft is researching this problem and will post new information as
 it becomes available.


 40. Linker Errors L4013, L2048, and L4038: Overlaying in OS/2

 Product Version(s): 5.01.20 | 5.03
 Operating System:   MS-DOS  | OS/2
 Flags: ENDUSER | S_C H_Fortran
 Last Modified: 21-JUN-1989    ArticleIdent: Q45619

 The linker does not overlay files when linking with protected mode
 run-time libraries. If told to overlay a program that is being linked
 with a protected mode run-time library, the linker responds with one
 or more of the following errors:

    LINK : warning L4013: invalid option for new-format executable file
    ignored
    LINK : error L2048: Microsoft Overlay Manager module not found
    LINK : warning L4038: program has no starting address

 possibly followed by (in DOS):

    run-time error R6001
    - null pointer assignment

 or possibly followed by (in OS/2):

    A general protection (GP) fault. It may also go into an infinite
    loop after creating the temporary file (for large executables).

 The workaround is to create two versions of the executable, an
 overlayed DOS version and a non-overlayed OS/2 version.

 Microsoft is researching this problem and will post new information as
 it becomes available.


 41. Link Error L1005: /PACKCODE: Packing Limit Exceeds 65,536

 Product Version(s): 3.65
 Operating System:   MS-DOS
 Flags: ENDUSER | docerr
 Last Modified: 21-JUN-1989    ArticleIdent: Q45724

 The Microsoft Overlay Linker Version 3.65 presents the following error
 message when the /PACKCODE: switch is used with a value greater than
 65,536 (64K):

    Link Fatal Error L1005:

 No error message text is supplied, and the error cannot be referenced
 in the Microsoft C 5.10 "CodeView and Utilities, Microsoft Editor,
 Mixed-Language Programming Guide." The error message should read as
 follows:

    Link Fatal Error L1005: /PACKCODE: Packing Limit Exceeds 65,536

 The error is reported correctly by the Microsoft QuickC Linker Version
 4.06 and all 5.0x versions of the Microsoft Segmented-Executable
 Linker. It is correctly documented in the Version 2.00 "Microsoft
 QuickC Tool Kit," on Page 278, and on Page 373 of the Version 5.00
 "Microsoft FORTRAN, Microsoft CodeView and Utilities User's Guide"
 manual, as follows:

    The value supplied with the /PACKCODE option exceeds the limit of
    65,536 bytes.


 42. What the /HIGH and /DS Linker Options Do

 Product Version(s): 3.65
 Operating System:   MS-DOS
 Flags: ENDUSER | SR# G890607-19979
 Last Modified: 13-JUL-1989    ArticleIdent: Q46745

 Question:

 I would like information on the /HIGH and /DS options of the linker.
 Specifically, what changes are needed in the .EXE file to tell the
 loader to put it high?

 Response:

 Basically, these are hold-over features from DOS Version 1.00 and from
 the original Microsoft/IBM Pascal and FORTRAN Compilers -- they're of
 little or no use under DOS 2.00 and later. Specifically, programs
 linked with the /HIGH switch are allocated all of the memory in the
 machine and cannot release unneeded memory back to DOS; therefore, no
 other program can be loaded into memory.

 The /HIGH switch sets both the minalloc and maxalloc fields in the .EXE
 header to zero. This combination of values causes the loader to load
 the program in high memory.

 /DSALLOCATE (or /DS) causes DGROUP to be "shifted" upwards so that the
 high address in the group is always FFFFh. Offsets into DGROUP are
 adjusted appropriately.

 These switches are strictly incompatible with our current high-level
 languages -- the only possible use for them is in a MASM program.
 Microsoft doesn't recommend using them at all unless you know
 precisely what you're doing.

 There is good documentation on what the /HIGH and /DSALLOCATE switches
 do, as well as how the loader works, in the "MS-DOS Encyclopedia,"
 starting on Page 719. (This excellent reference manual is now less
 expensive and available in paperback).


 43. How Minimum Load Size Is Calculated

 Product Version(s): 3.65
 Operating System:   MS-DOS
 Flags: ENDUSER | SR# G890607-19979
 Last Modified: 13-JUL-1989    ArticleIdent: Q46774

 The MS-DOS program loader uses the following formula to calculate the
 number of 16-byte paragraphs to use when loading a program:

    TotPages * 20h - NumHeader + 10h + MaxAlloc

 The formula calculates the number of 16-byte paragraphs, unless
 there's not enough memory, in which case all the available memory is
 used. If there are not at least

    TotPages * 20h - NumHeader + 10h + MinAlloc

 paragraphs available, DOS cannot and will not load the program.

 The 20h is the size of a page in paragraphs, which is the size of a
 page (512 bytes) divided by the size of a paragraph (16 bytes).

 The 10h is the size in paragraphs of the 256-byte Program Segment
 Prefix that precedes all programs in memory.

 All of the values used in the formulae shown above are words (shown in
 the following) that are stored in standard Intel low-byte-first format
 in the .EXE file header:

    Value           Name used by EXEHDR             Offset in .EXE header
    -----           -------------------             ---------------------

    TotPages        Pages in file                   4 - 5
    NumHeader       Paragraphs in header            8 - 9
    MinAlloc        Extra paragraphs needed         0Ah - 0Bh
    MaxAlloc        Extra paragraphs wanted         0Ch - 0Dh

 For more information, refer to a good MS-DOS reference such as the
 "MS-DOS Encyclopedia."


 44. L1074 Name: Group Larger Than 64K Bytes

 Product Version(s): 4.06
 Operating System:   MS-DOS
 Flags: ENDUSER | S_C S_QuickC
 Last Modified: 24-JUL-1989    ArticleIdent: Q46996

 The Microsoft QuickC Compiler Version 2.00 returns the following
 linker error message when the size of DGROUP (the default data
 segment) exceeds 64K:

    L1074 name: group larger than 64K bytes

 This error is documented on Page 282 of the "Microsoft QuickC Tool
 Kit" manual as follows:

    The given group exceeds the limit of 65,536 bytes.

    Reduce the size of the group, or remove any unneeded segments from
    the group (refer to the map file for a listing of segments).

 There are four ways to resolve this data segment overflow when using
 QuickC:

 1. Reduce the stack size in order to reduce the size of DGROUP. In the
    environment this can be done in the Options.Make.Linker Flags menu.
    Outside the environment this can be done at compile time with the
    "/F hexnum" switch, where hexnum is the size of the requested stack
    in hexadecimal format. Outside the environment, at link time, this
    can be done with the "/ST:decnum" switch, where decnum is the size
    of the requested stack in decimal format.

 2. Declare data with the FAR keyword to move it out of DGROUP.

    Note: In the small and medium memory models the Microsoft run-time
    library functions can no longer be used with this data. You must
    copy this far to a near heap location, before you use the run-time
    routines on this data.

 3. Outside the environment, compile in the compact, large, or huge
    memory models with the "/GtX" switch, where X is a data threshold.
    All data items larger than X bytes are moved out of DGROUP into a
    far data segment.

 4. Reduce the amount of data declared in the program. In the compact,
    large, and huge memory models, try dynamically allocating space for
    the data. Memory can also be dynamically allocated outside DGROUP
    in the small and medium memory models by using _fmalloc() but, as
    stated in Number 2, the run-time library functions do not work with
    this data.

    Reduce the amount of string literals in this default data segment by
    reading from a data file at run time, or in C 5.00, by using the
    /Gt patch to allow string literals to be moved from the _CONST
    segment in DGROUP into a far segment.


 45. /CP:X Is Not Valid When Linking Protected-Mode Programs

 Product Version(s): 5.01.21 | 5.01.21
 Operating System:   MS-DOS  | OS/2
 Flags: ENDUSER | docerr
 Last Modified: 26-JUL-1989    ArticleIdent: Q47036

 Question:

 I cannot seem to get the /CPARMAXALLOC linker option to work when I
 link for OS/2 protected mode. When linking a real-mode application, it
 works correctly. Also, when I type "link /help" in protected mode, the
 output indicates that this is a valid option. However, when I try to
 use this option for a protected-mode application, the linker produces
 the following warning:

    LINK : warning L4013: invalid option for new-format executable file
                          ignored

 What am I doing wrong and what does this error message mean?

 Response:

 As documented on Page 27 in the update section of the Microsoft C
 Optimizing Compiler Version 5.10 "CodeView and Utilities, Microsoft
 Editor, Mixed-Language Programming Guide" manual, the /CPARMAXALLOC
 option is for real-mode applications only. The "link /help" indicates
 that this is a valid option because this option IS valid whenever
 you're linking real-mode applications, regardless of whether the
 linker is running under OS/2 or DOS. (By the same token, it is invalid
 when you're linking a protected-mode application, regardless of which
 operating system you're using.)

 This error message was omitted from the documentation. It indicates
 that one of the options that the linker was passed is invalid.

 This option is not supported in a protected-mode application because
 the functionality of it is done automatically by the linker.
 Protected-mode applications are not given a 64K default data segment;
 they are only allocated the space that they need. This is documented
 on Page 33 of the same section and manual listed above.


 46. Cannot Use Overlays in a Bound Application

 Product Version(s): 5.01.21 5.03 | 5.01.21 5.03
 Operating System:   MS-DOS       | OS/2
 Flags: ENDUSER |
 Last Modified: 30-AUG-1989    ArticleIdent: Q47104

 Question:

 How can I incorporate overlays into my bound application?

 Response:

 You cannot use overlays in a bound application. To bind an
 application, you must first have a runnable OS/2 executable; then, you
 use the BIND utility to make it run in both OS/2 and DOS. OS/2
 executables do not understand overlays so you cannot incorporate them
 into an OS/2 executable. Hence, you cannot use overlays in a bound
 program.


 47. Linker Error L1063 and Linking Over 1000 Object Modules

 Product Version(s): 5.01.21 5.03
 Operating System:   OS/2
 Flags: ENDUSER | S_C S_CodeView
 Last Modified: 16-AUG-1989    ArticleIdent: Q47931

 Question:

 When attempting to link a large OS/2 application consisting of over
 1500 object modules with C 5.10's Link 5.01.21 or FORTRAN 5.00's Link
 5.03 by using the options /co /map:2078 /noe /se:2078 /packcode, I get
 the link error "L1063 out of memory for CodeView information." Only
 one of the .C source files was compiled with /Zi. All were compiled
 with /AL. Linking without /co (CodeView information) successfully
 produces a 700K executable file (.EXE), but I need to do some
 debugging with CVP.

 What is the L1063 error, and how can I work around it?

 Response:

 Information on L1063 is not in the C 5.10 text files or documentation,
 but it is in Pascal 4.00's README.DOC and in FORTRAN 4.10's
 CVREADME.DOC as noted in another article in this knowledge base. The
 following reiterates the error message and its description:

    L1063 out of memory for CodeView information

    The linker was given too many object files with debug information,
    and the linker ran out of space to store it. Reduce the number of
    object files that have debug information.

 In this case, it is not the number of modules with CodeView
 information that is causing the problems exactly; it is the great
 number of modules and trying to link in any CodeView information.

 The following are ways to workaround this linker limitation:

 1. The most effective method is to demodularize your application. That
    is, put more functions into fewer .C source files.
 2. Reduce the linker option /se: value to as low as possible for the
    number of logical segments in the application.
 3. Link the object files from the current working directory. If you
    must use different directories for your .OBJs, make the pathnames
    as short as possible.


 48. Description of a Linker .MAP File

 Product Version(s): 3.60 3.61 3.64 3.65 5.01.20 5.01.21 5.03  | 5.01.20 5.01.
 Operating System:   MS-DOS                                    | OS/2
 Flags: ENDUSER | S_C S_PasCal H_FORTRAN
 Last Modified: 19-SEP-1989    ArticleIdent: Q47960

 A .MAP file generated by the linker is a listing of the addresses and
 names of a program, as follows:

    Logical Segments
    Groups (defined collections of logical segments)
    Public Symbols listed by name
    Public Symbols listed again by their relative address
    Entry Point address (first executable instruction)

 A linker .MAP file (with a .MAP file extension) contains the address,
 size, name, and class of logical code and data segments. (One or more
 logical segments of either code or data can be combined into a
 physical segment of either code or data, respectively, by the linker.)

 In DOS or real-mode OS/2, the addresses are 20-bit hex addresses that
 are RELATIVE to the beginning of the program's load image. In
 protected-mode OS/2, the hex addresses are in 32-bit segment
 selector:offset notation (16 bits for the segment selector and 16 bits
 for the offset) starting with segment selector 1.

 The _TEXT segment names of class CODE are the code in your object
 files. The various forms of near logical data segments are described
 in the DGROUP diagram, which you probably already have. (Briefly,
 _DATA is initialized near global data, _BSS is uninitialized near
 "static" data, C_COMMON is uninitialized near data, and CONST is for
 floating point constants. FAR_DATA and HUGE_DATA are global
 initialized far and huge data, respectively, and FAR_BSS is global
 unitialized far or huge data.)

 Next in the .MAP is the ORIGIN (address) and name of the defined
 groups of logical segments, notably DGROUP, which is used in our
 high-level languages for grouping many logical data segments into the
 "default" physical data segment. The name "default" data segment
 refers to the fact the the DS register will point to this segment by
 default so that offset (near) addressing can be used without loading
 the DS register. Groups allow multiple logical segments to be
 associated with the same starting address, so near (non-far) data in
 Microsoft high-level languages is addressed relative to DGROUP.

 Following the segment descriptions, under the heading of "Publics by
 Name", the names of Public symbols (i.e., global or extern functions,
 including numerous internal C library functions, and variables) are
 listed in ASCII order (capital letters first, then lowercase letters,
 and finally underscores) along with their hex relative segment:offset
 addresses (or segment selector:offset in protected-mode OS/2). Public
 symbols are then listed again, in order of their relative
 segment:offset addresses under the heading "Publics by Value".

 Only Public (e.g. global) symbols such as function and variable names
 appear in the .MAP. No "static" functions or data, "auto" storage
 class data (e.g. local function data), or data types are listed in the
 .MAP.

 A high-level language such as C creates many logical segments in
 DGROUP for "internal" (e.g. undocumented) purposes, calls numerous
 internal library functions, and refers to variables for the main
 program initialization and start-up code. C refers to additional
 initialization functions and variables for the library functions that
 your program explicitly calls, still more for floating point
 functions, as well as termination functions.

 To get an idea of the functions automatically linked in from the C
 library, generate and compare .MAP files for simple source modules
 such as foo(){} or main(){}, main(){puts("hi");}, and a small program
 that performs floating point arithmetic or calls a C library floating
 point math function that calls "fp..." routines.

 The "Program entry point" is the last item in the .MAP file. It refers
 to the segment:offset address of the first instruction of the program
 to be executed, relative to the lowest memory address in the .EXE load
 image.

 For more information on the entry point, please use the following
 query:

    .map file's program entry point


 49. Linker Can Indiscriminately Bind Different Types

 Product Version(s): 1.x 2.x 3.x 4.x 5.01 5.02 5.03 | 5.01
 Operating System:   MS-DOS                         | OS/2
 Flags: ENDUSER | S_C S_QuickC S_QuickASM S_Pascal S_QuickPas
 Last Modified:  2-AUG-1990    ArticleIdent: Q48204

 The object module format used by the Microsoft languages contains a
 record type that is used to bind symbol definitions to symbol
 references in other modules. This record is known as a "fixup." As
 defined by Intel, the fixup record type contains no information as to
 the type of data that is to be fixed up. Under certain circumstances,
 this can cause unexpected and undesired binding at link time. The code
 below demonstrates such an instance:

     /*----- FILE1.C -----*/

     void bar( void );

     void main( void )
     {
         bar();
     }

     /*----- FILE2.C -----*/

     int bar;

 These files both compile without error. When compiled for a model with
 a single code segment, linker error L2003 is produced saying that an
 intersegment self-relative fixup was attempted. If a multiple code
 segment model is used, no link errors are produced. Although a clean
 link can be obtained, the resultant EXE does not perform as expected
 due to the fact that the function reference of bar in FILE1.C has been
 bound to the integer definition of bar in FILE2.C.

 The linker has no way of determining the types of the reference to,
 and definition of, bar. This is a limitation of the object file
 format. If an include file was used to prototype bar and was then
 included in both files, the compiler could have detected the
 redefinition of bar.

 This information applies to all 1.x, 2.x, and 3.x versions of LINK
 including 3.60, 3.61, 3.64, and 3.65, as well as LINK Versions 4.06,
 4.07, 5.01, 5.02, and 5.03.


 50. Novell Network Software May Cause L1084 Error

 Product Version(s): 5.03
 Operating System:   MS-DOS
 Flags: ENDUSER | h_fortran h_masm s_c s_pascal
 Last Modified: 23-JAN-1990    ArticleIdent: Q57304

 The resident software used to access a Novell network may cause the
 following error when linking large programs:

    L1084:  Cannot create temporary file

 This problem was observed with Netware versions 2.10 SFT and 2.15 of
 the Novell network software.


 51. Relationship between Map File Addresses and Location in Memory

 Product Version(s): 3.61 3.65
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 19-SEP-1989    ArticleIdent: Q48241

 In situations where memory is very short or where CodeView interacts
 with your program, it is sometimes necessary to use the DEBUG.COM
 program supplied with DOS.

 Using DEBUG is more difficult than using SYMDEB or CodeView because
 DEBUG has no symbolic features. You must use the map produced by the
 /M option when you link with a standard DOS overlay linker (i.e., not
 a segmented executable linker) to locate specific parts of your
 program.

 However, since DOS relocates programs when it loads them, the
 addresses given in the map need conversion before you can use them.

 This conversion is simple: DOS adds the address of the start segment
 (defined below) to each segment address in the load map. The offsets
 never change from the values shown in the link map -- only the
 segments change.

 The start segment is the base address of the Program Segment Prefix
 (PSP) plus the size of the PSP in paragraphs. Since the PSP is always
 100h (256) bytes long, the size of the PSP is 10h paragraphs.

 Note: DOS puts the base segment address of the PSP in DS and in ES
 when a program begins execution.

 For example, assume that the link map says that the function _funct is
 at 0004:05A0 (all values in hex) and that the global variable _errno
 is at 0192:00E3. Suppose further that when the program is loaded into
 DEBUG, the DS and ES registers contain 2BA5 -- the segment address of
 the PSP. (Use the R command to display the values of the registers.)

 The start segment for loading the program will be 2BB5 -- the value of
 the PSP base address (2BA5) + 10h to allow for the 10h paragraph
 length of the PSP (100h bytes).

 Thus, the function _funct will be located as follows:

    0004:05A0   -- address of _funct in the link map
    2BB5        -- start segment address (PSP + 10h)
    ---------
    2BB9:05A0

 And _errno will be located as follows:

    0192:00E3   -- address of _funct in the link map
    2BB5        -- start segment address (PSP + 10h)
    ---------
    2D47:00E3

 Use this calculation on any address in the link map to find where the
 symbol is located in memory when actually loaded.

 The H (Hex Arithmetic) command in DEBUG can be helpful when performing
 these calculations, as can a hex calculator with constant feature.


 52. Warning L4014: /PACKDATA: Option Ignored for Real Mode

 Product Version(s): 4.06 4.07 5.02 5.03 | 5.02 5.03
 Operating System:   MS-DOS              | OS/2
 Flags: ENDUSER |
 Last Modified: 21-SEP-1989    ArticleIdent: Q48839

 /PACKDATA is incorrectly listed as an available switch for LINK
 Versions 4.06 and 4.07. LINK Version 4.06 comes with the QuickC
 compiler, and LINK Version 4.07 comes with the QuickAssembler.

 The /PACKDATA option is valid ONLY for segmented-executable files --
 OS/2 or Windows; it has no meaning for DOS. Real mode executable means
 a DOS-only program. To use the /PACKDATA switch, create a .DEF file
 with at least the following statement:

    NAME    MyProtectModeProgram

 This switch is implemented in segmented-executable LINK Versions 5.02
 and later.


 53. /NOI Switch May Cause L2022 and L2029 in PM Programs

 Product Version(s): 5.10   | 5.10
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified: 27-OCT-1989    ArticleIdent: Q49008

 I am compiling and linking a Presentation Manager (PM) program from
 Charles Petzold's "Programming the OS/2 Presentation Manager" and I
 get the following link errors:

    LINK : error L2022: ClientWndProc (alias ClientWndProc) : export
           undefined

         : error L2029 : 'ClientWndProc' : unresolved external

 I get the same errors when compiling WELCOME1.C from the companion
 disk to "Programming the OS/2 Presentation Manager."

 The /NOI switch instructs the linker to preserve case. If you are
 using the /NOI switch, the linker will generate these errors because
 EXPENTRY (the export entry point) is defined in OS2DEF.H as follows:

    #define EXPENTRY far pascal

 The "pascal" keyword instructs the compiler to use the left-to-right
 calling sequence for the functions that it modifies. The keyword also
 causes the conversion of the function's name to uppercase letters.

 All window procedures are defined as EXPENTRY. Thus, the name of your
 window procedure is converted to uppercase letters. In your .DEF, you
 export your window procedures as follows:

    EXPORTS         ClientWndProc

 Because of the /NOI switch, the linker does not view ClientWndProc and
 CLIENTWNDPROC as being equal. Consequently, you get the first error
 message "export undefined."

 The second error message is generated because ClientWndProc (mixed
 uppercase and lowercase letters) is not recognized as being defined,
 so the linker considers it an "unresolved external."

 Removing the /NOI switch from your link line corrects both errors.


 54. LINK 5.03 and Later Require EXETYPE WINDOWS in .DEF File

 Product Version(s): 5.03
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 17-JUL-1990    ArticleIdent: Q49445

 Microsoft LINK (LINK.EXE) versions 5.03 and later require that the
 WINDOWS descriptor be placed in the EXETYPE section of your project's
 .DEF (definitions) file if you are developing a Windows' application.

 This marks a change from previous linkers' behavior, which would allow
 the programmer to fail in specifying the type of executable to be
 created, but still produce a Windows-compatible .EXE file. This
 failure is no longer acceptable to LINK Versions 5.03 and later.

 If you fail to inform the linker (via the .DEF file) that you are
 creating a Windows executable, the linker reaches completion but the
 resulting .EXE does not execute.

 To specify the executable type, you must create a .DEF file and submit
 this to the linker at link time. For example, if you had a project
 called WINTEST.C, you must modify WINTEST.DEF so that it contains the
 following line:

    EXETYPE   WINDOWS

 The default EXETYPE is OS/2, as stated in the "Microsoft FORTRAN,
 CodeView and Utilities User's Guide" packaged with FORTRAN Version
 5.00.

 For further information regarding the definitions file and other
 descriptors, consult Section 7, "Using Module-Definition Files," in
 the "CodeView and Utilities, Microsoft Editor, Mixed Language
 Programming Guide" (Update Section) for C 5.10.

 LINK Version 5.03 is shipped with the FORTRAN version 5.00 package.


 55. Long TMP Environment Variable Causes L1089

 Product Version(s): 5.03   | 5.03
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | h_fortran
 Last Modified:  6-DEC-1989    ArticleIdent: Q48869

 L1089 occurs when the LINK Utility Version 5.03 is called from FORTRAN
 Version 5.00 and the TMP environment variable is set to a long
 pathname.

 Normal troubleshooting indicates that the TMP variable is corrupt, but
 this is not the case. It seems that the temporary filename is being
 truncated.

 The following sequence produces the error if the subdirectory
 D:\COMPILER\FORTRAN5\TMP\ already exists:

 SET TMP=d:\compiler\fortran5\tmp
 fl sieve.for

 LINK : fatal error L1089: D:\COMPILER\FORTRAN5\TMP\000054l
 : cannot open response file

 This problem occurs in FORTRAN 5.00 and Link 5.03.


 56. L2041: Stack Plus Data Exceeds 64K -- Documentation Supplement

 Product Version(s): 3.65 4.06 | 5.01.21
 Operating System:   MS-DOS    | OS/2
 Flags: ENDUSER  | s_pascal h_fortran h_masm s_c s_quickc s_quickasm s_error d
 Last Modified: 30-NOV-1989    ArticleIdent: Q50130

 The following indicates that there is more than 64K of stack and data
 to be put into the 64K DGROUP (default data segment):

    L2041    stack plus data exceeds 64K

             The combined size of the program stack segment plus DGROUP
             was greater than 64K; as a result, the program will not
             load up correctly.

 To correct this problem, do the following:

 1. If the file(s) was compiled with C 5.00, a large amount of string
    literal data in the program may cause this error. Unlike C 5.10,
    5.00 cannot move string literals out of DGROUP with the /Gt option.
    This problem can be corrected with the "C 5.00 /Gt Fix" application
    note, which is available from Microsoft Product Support Services by
    calling (206) 454-2030.

 2. Reduce the stack size.

 3. Use a large data model (compact, large, or huge). Try applying the
    /Gt compilation option to lower the threshold.

 4. Use the FAR keyword to move data out of DGROUP.

 This error is documented in "Linker Error Messages" in the "Microsoft
 QuickC Compiler for IBM Personal Computers and Compatibles
 Programmer's Guide," Section D.4, Page 374. It is also in the file
 ERRMSG.DOC on Compiler Disk 1 for Microsoft C Version 5.10, on the
 Setup disk for Microsoft C Version 5.00, in the file README.DOC on
 Disk 1 for Microsoft Macro Assembler Version 5.10, and in the file
 CVREADME.DOC on the CodeView for MS-DOS disk for Microsoft FORTRAN
 Version 4.10. It is not found in the "CodeView and Utilities,
 Microsoft Editor, Mixed-Language Programming Guide" manual.

 Nonfatal errors indicate problems in the executable file. LINK
 produces the executable file. Nonfatal error messages have the
 following format:

    location : error L2xxx: messagetext

 In these messages, location is the input file associated with the
 error, or LINK if there is no input file. If the input file is an .OBJ
 or .LIB file and has a module name, the module name is enclosed in
 parentheses.

 Additional reference words: appnote


 57. Link Error L2028 Caused by HEAPSIZE, STACKSIZE and DGROUP Size

 Product Version(s): 5.01.21 | 5.01.21
 Operating System:   MS-DOS  | OS/2
 Flags: ENDUSER | docerr
 Last Modified: 17-JUL-1990    ArticleIdent: Q49935

 The error L2028 "Automatic data segment plus heap exceeds 64K" was
 omitted from the linker error messages in the "CodeView and Utilities,
 Microsoft Editor, Mixed-Language Programming Guide" manual that
 accompanies Microsoft C 5.10. This error occurs when the stack and
 data plus the near heap exceeds 64K. The near heap size is set with
 the HEAPSIZE option in the .DEF file.

 The error can be corrected by using one of the following methods:

 1. Reducing the amount of data in the default data segment.

 2. Decreasing the stack size that was set by /ST:xxxx at the link line
    or by the STACKSIZE option in the .DEF file.

 3. Decreasing the amount of near heap that is being requested with the
    HEAPSIZE option in .DEF file.


 58. Specifying Link Options with "-" Causes L4046, L1083, or U1013

 Product Version(s): 5.01.21
 Operating System:   OS/2
 Flags: ENDUSER |
 Last Modified: 10-NOV-1989    ArticleIdent: Q50333

 LINK command line switches must begin with the linker's option
 character, the forward slash (/). While it is valid to begin
 compilation switches with a dash (-), the same is not true for the
 linker.

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

 #--------------------
 # test make file
 #--------------------

 test.obj : test.c test.h
      cl -c -Zi -G2sw -W3 test.c

 test.exe : test.obj test.def
      link test, -CO -align:16, NUL, os2, test

 You type:
         make test

 Microsoft (R) Program Maintenance Utility  Version 4.07
 Copyright (C) Microsoft Corp 1984-1988. All rights reserved.

   link test, -CO -align:16, NUL, os2, test

 Microsoft (R) Segmented-Executable Linker  Version 5.01.21
 Copyright (C) Microsoft Corp 1984-1988.  All rights reserved.

 TEST.DEF(12) : warning L4046: module name different from output file name
 LINK : fatal error L1083: cannot open run file
 test(16) : fatal error U1013: 'link test, -CO -align:16, NUL, os2, test'
          : error 2


 59. /PACKCODE Incompatible with IOPL Segments with LINK 5.01.21

 Product Version(s): 5.01.21
 Operating System:   OS/2
 Flags: ENDUSER | S_C
 Last Modified: 10-NOV-1989    ArticleIdent: Q50702

 LINK Version 5.01.21 does not support the combination of using the
 /PACKCODE switch and having code segments declared as IOPL (i.e., as
 having I/O privilege).

 When combining segments as directed by the /PACKCODE option, LINK
 5.01.21 will combine the IOPL segment(s) with other segments that do
 not have I/O privilege. The result is an invalid executable that
 returns the system error SYS1059 when it is invoked.

 The lack of ability to combine these options is a limitation of this
 particular linker version. LINK Version 5.03 allows the combination of
 /PACKCODE and IOPL segments without a problem.


 60. LINK : Warning L4011 Caused By Invalid /PACKCODE Group Size

 Product Version(s): 3.65 4.06 4.07 5.01.21 5.03 | 5.01.21 5.03
 Operating System:   MS-DOS                      | OS/2
 Flags: ENDUSER | S_C S_QUICKC S_QUICKASM S_PASCAL DOCERR
 Last Modified: 10-NOV-1989    ArticleIdent: Q50705

 The LINK code packing option, /PAC[:n], groups together neighboring
 code segments into the same segment of maximum size "n" bytes. The
 results of using /PAC will only be reliable when "n" is in the range
 of 0 to 65500. Page 278 of the "Microsoft C 5.1 CodeView and
 Utilities" reference manual states the default value for "n" is 65530.
 This is incorrect.

 The linkers from the following products were tested with the /PAC
 option to determine their behavior with various values of "n":

    C 5.10
    Pascal 4.00
    FORTRAN 5.00
    QuickC 1.01
    QuickC 2.00
    QuickASM 2.01

 Note: Linkers were checked in both real and protected mode where
 appropriate.

 The following table shows the acceptable values that can be used with
 the /PAC[:n] option and what error message will occur when the value
 of "n" is out of range:

 ----------------------------------------------------------------------
 Value of "n"      LINK Vers.   Error Message
 ----------------------------------------------------------------------
 0 to 65500        3.65         No Errors/Warnings
                   4.06         No Errors/Warnings
                   4.07         No Errors/Warnings
                   5.01.21      No Errors/Warnings
                   5.03         No Errors/Warnings

 65501 to 65536    3.65         LINK : warning L4011:
                   4.06         LINK : warning L4011: PACKCODE value
                                exceeding 65500 unreliable
                   4.07         (same as above)
                   5.01.21      (same as above)
                   5.03         (same as above)

 65537 and over    3.65         LINK : fatal error L1005:
                   4.06         LINK : fatal error L1005: packing limit
                                exceeds 65536 bytes
                   4.07         (same as above)
                   5.01.21      (same as above)
                   5.03         (same as above)
 ----------------------------------------------------------------------

 Note : With LINK Version 5.03 and later, the /PAC option has been
 changed to /PACKC to differentiate /PACKC[ODE] from the new
 /PACKD[ATA] option.


 61. How and When to Specify Stack Size (Clarification)

 Product Version(s): 3.65 4.06 4.07 | 5.01.21
 Operating System:   MS-DOS         | OS/2
 Flags: ENDUSER |
 Last Modified: 30-NOV-1989    ArticleIdent: Q50950

 Question:

 When I want to specify a certain stack size for a program, should I
 use the /F compiler option, the /ST linker option, or both?

 Response:

 This depends on how you are compiling and linking. If you using the CL
 command to compile and link, the /F compiler option is all that is
 necessary. This option will pass the correct size of the stack to the
 linker.

 On the other hand, if you are invoking the compiler and the linker
 separately (as in a make file), the /ST link option can be used to get
 the desired stack size. The /ST link option is documented on Page 123
 of the "Microsoft C Optimizing Compiler User's Guide."

 No stack information is stored in the object module. Therefore, using
 the /F and /c (compile only) options together and then invoking link
 separately will not generate the desired stack size. The /F compile
 option is documented on Page 102 of the "Microsoft C Optimizing
 Compiler User's Guide."


 62. Linking Method May Result in Unexpected Increase in .EXE Size

 Product Version(s): 3.x 4.06 4.07 5.01.21 5.03 | 5.01.21 5.03
 Operating System:   MS-DOS                     | OS/2
 Flags: ENDUSER |
 Last Modified: 21-FEB-1990    ArticleIdent: Q58689

 Question:

 When my program is linked in the following manner

    link  file1.obj file2.obj library.lib;

 the resulting executable file is much larger than if the program is
 linked this way:

    link  file1.obj file2.obj,,,library.lib;

 What causes the difference in size?

 Response:

 This is expected behavior, the difference in size is due to the
 difference in linking method.

 The first method has the library name in the same field as the object
 files. Libraries entered in this field are called "load libraries" as
 opposed to "regular libraries." Link automatically links in every
 object module in a load library; it does not search for unresolved
 external references first.

 The effect of using a load library is exactly the same as if you had
 entered all the names of the library's object modules as separate
 object files on the link command line. This feature is useful if you
 are developing software using many modules and want to avoid having to
 retype each module on the LINK command line.

 With the second method, LINK links in only the objects from the
 library that are required for program execution.

 Please see documentation on LINK, such as Section 12.1.2 of the
 Microsoft C 5.1 "CodeView and Utilities Software Development Tools for
 the MS-DOS Operating System" manual (Page 257) for more information.


 63. Linker Uses Library Sequence to Resolve External References

 Product Version(s):
 Operating System:   1.x 2.x 3.x 4.06 4.07 5.01.21 5.02 5.03 | 5.01.21 5.02 5.
 Flags: MS-DOS                                  | OS/2
 Last Modified: 26-FEB-1990    ArticleIdent: Q57706
 ENDUSER |

 "The MS-DOS Encyclopedia," Pages 407 and 408, states the following:

    When a public symbol required to resolve an external reference is
    declared more than once among the object modules in the input
    libraries, LINK uses the first object module that contains the
    public symbol. This means that the actual executable code or data
    associated with a particular external reference can be varied by
    changing the order in which LINK processes its input libraries...

    Each individual library is searched repeatedly (from first library
    to last, in the sequence in which they are input to LINK) until no
    further external references can be resolved.

 The following simple case demonstrates the concept:

    Module MAIN   Library A     Library B1    Library C     Library B2
    +---------+   +----------+  +----------+  +----------+  +----------+
    | calls A |   | contains |  | contains |  | contains |  | contains |
    +---------+   |    A,    |  |    B     |  |    C,    |  |    B     |
                  | calls  C |  +----------+  | calls  B |  +----------+
                  +----------+                +----------+

 The linker determines which copy of Module B to use depending on the
 library sequence. For example, when you link with the following, the
 Module B from Library B2 is selected:

    LINK MAIN,,,A B1 C B2;

 The linker looks first in Library C and, unable to resolve the
 reference, proceeds to the next library, B2. If the linker is still
 unable to resolve the reference, it continues searching at Library A.

 A slightly more complex case, when Library A contains both Module A
 and Module B, produces different results, as shown below:

    Module MAIN   Library A     (remove B1)   Library C     Library B2
    +---------+   +----------+                +----------+  +----------+
    | calls A |   | contains |                | contains |  | contains |
    +---------+   |    A,    |                |    C,    |  |    B     |
                  | calls  C |                | calls  B |  +----------+
                  +----------+                +----------+
                  | contains |
                  |    B     |
                  +----------+

 Link with "LINK MAIN,,,A C B2;". In this case, Module B from Library A
 is selected.

 Although the linker always follows the same rules for resolution, it
 gets more difficult to determine which version of a module will be
 selected in more complex cases. When feasible, you can avoid this
 problem by putting your selected versions in an .OBJ instead of an
 .LIB. The linker uses any .OBJs to resolve references before it
 uses libraries.

 For more information, refer to "The MS-DOS Encyclopedia," Article 20:
 "The Microsoft Object Linker," in the "Object Module Order" section,
 Pages 703-706.


 64. Calling Overlaid Functions Through Pointers Not Supported

 Product Version(s): 1.x 2.x 3.x 4.06 4.07 5.01.21 5.02 5.03
 Operating System:   MS-DOS
 Flags: ENDUSER | S_C S_QuickC
 Last Modified: 30-JAN-1990    ArticleIdent: Q58098

 LINK does not support using function pointers for calling functions in
 overlays unless the function is being called from within the same
 overlay. If an overlaid function is being called from the root or from
 a different overlay, then the call must not be made through a pointer.

 LINK cannot support calling overlaid functions indirectly through
 pointers because the address of the indirect function is determined at
 load time.

 In a program with overlays, a normal function call (that is, not a
 call through a pointer) is recognized by the linker and an interrupt
 call is placed into the .EXE in place of the function call. When the
 function is called at run time, the interrupt directs control to the
 overlay manager. The overlay manager checks whether the right overlay
 is loaded into memory, loads it if necessary, and calls the function.
 Because there is a fixup record in the .OBJ for the function call, the
 linker can set everything up correctly.

 On the other hand, with a function pointer, the compiler creates a
 fixup record for the address that the pointer references. However,
 there is no indication in the fixup record that this address is for a
 function. Therefore, if you link the function in as an overlay, the
 linker does not insert a call to the overlay manager and instead does
 a standard fixup.

 As a result, if you indirectly call a function located in a not-as-yet
 loaded overlay, the overlay does not get loaded. Nevertheless, control
 is still transferred to the address at which the function is thought
 to reside, which can only mean disaster for the executing program.


 65. /PAU Linker Option Doesn't Function in Some Versions of LINK

 Product Version(s): 3.61 3.65 3.69 5.01.20 5.05 | 5.01.20 5.05
 Operating System:   MS-DOS                      | OS/2
 Flags: ENDUSER |
 Last Modified: 21-FEB-1990    ArticleIdent: Q58781

 The /PAU (PAUSE) linker option tells LINK to pause in the link session
 and display a message before it writes the executable file to disk,
 allowing you to insert a new disk on which to store the executable
 file.

 In Microsoft LINK.EXE Versions 3.61, 3.65, 3.69, 5.01.20, and 5.05,
 the /PAU linker option does not pause the link session.

 Microsoft is researching this problem and will post new information
 here as it becomes available.

 In versions where the /PAU linker option functions correctly, LINK
 displays the following message before it creates the executable file:

    About to generate .EXE file
    Change diskette in drive ___ and press <ENTER>

 LINK resumes processing after the ENTER key is pressed.


 66. /INC and Overlays Are Not Supported at the Same Time

 Product Version(s): 5.01.20 5.01.21 5.02 5.03
 Operating System:   MS-DOS
 Flags: ENDUSER | docsup
 Last Modified: 15-MAY-1990    ArticleIdent: Q59279

 LINK.EXE does not support the use of /INCREMENTAL (or /INC) switch and
 overlays at the same time. This is because ILINK.EXE, which is invoked
 by the /INC option, does not support overlays. One of the two
 operations is ignored.

 The linker produces a working executable file, but one of the
 following WARNING messages may be produced:

    L4013: Overlays: option ignored for segmented-executable file
    L4014: /INCREMENTAL : Option ignored for realmode executable file

 If no warning message is produced, the linker takes an unpredictable
 path. If this is the case, the executable file that is produced could
 be corrupted and should NOT be relied upon.


 67. Incomplete EXPORTS List May Cause L2022 and L2029

 Product Version(s): 3.65
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 12-MAR-1990    ArticleIdent: Q59385

 Compiling and linking a Windows program and receiving the following
 two link errors can be caused by an incomplete EXPORTS list:

    LINK : error L2022: ProcedureName : export undefined
    LINK : error L2029: 'ProcedureName' : unresolved external

 Windows programming involves the creation of a .DEF (definitions)
 file. All Windows procedures to be exported must be listed in this
 file. The following is an example:

    EXPORTS     ProcedureName

 When this list is incomplete, the L2022 error is generated. The L2029
 error can be generated if the case of the EXPORT line doesn't match
 the case of the actual function.

 Listing all procedures to be exported in the .DEF file prevents both
 of these errors.

 Note: These errors can also occur with Presentation Manager programs
 or programs that use DLLs under OS/2.


 68. Why the /HIGH Switch Is Not Used with High-Level Languages

 Product Version(s): 3.65
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 15-MAR-1990    ArticleIdent: Q59535

 The linker option /HIGH is used with assembly language programs to
 load an .EXE file as high as possible in memory. Without the /HIGH
 option, LINK places the .EXE file as low as possible.

 /HIGH is not used with high-level languages because it prohibits the
 use of dynamic memory allocation by the program. Furthermore, C
 run-time start-up code specifies /DOSSEG, which forces low load and
 Microsoft run-time segment layout.

 When a program is linked with /HIGH, MS-DOS loads the program at the
 highest possible memory location available, usually 0xFFF0. All memory
 between the program's segments (which are high) and the program's PSP
 (which is low) is now considered program RAM, owned by the program.
 You can no longer allocate or free that memory.

 Therefore, calls to routines such as malloc() and free() fail. This
 causes problems for the following reasons:

 1. Some memory is dynamically allocated during function calls from
    high-level languages.

 2. The memory structure required by Microsoft high-level languages for
    tracking used/freed memory is not available.

 You can use /HIGH if you write your own start-up code, but your
 programs cannot call most of the routines from the C run-time library.

 The only reason /HIGH is still available to the linker is that early
 versions of Microsoft FORTRAN and Microsoft Pascal generated code that
 had to be linked with /DSALLOCATE, which relocates all addresses
 within DGROUP in such a way that the last byte in the group has the
 offset 0xFFFF. The /HIGH switch is used in conjunction with the
 /DS(ALLOCATE) switch.

 For more information, search the knowledge base with the following
 query:

    S_LINK and /HIGH and /DS

 You can also read the section "Using the /HIGH and /DSALLOCATE
 Switches" on Page 719 ff in the "MS-DOS Encyclopedia."


 69. OS/2 Module Definition File Syntax

 Product Version(s): 5.01.21 5.02 5.03 5.05
 Operating System:   OS/2
 Flags: ENDUSER | S_C
 Last Modified: 16-MAR-1990    ArticleIdent: Q59536

 The following is extracted from Ray Duncan's "Advanced OS/2
 Programming," Page 737:

    Module definition (DEF) files are simple ASCII text files that are
    interpreted by the linker during the construction of an application
    program, dynlink library, or device driver. The directives in DEF
    files cause information to be built into the executable file's
    header, which is later interpreted by the system when the program,
    library, or driver is loaded.

    Enter all DEF file directives and keywords in uppercase letters.
    File, segment, group, and procedure names can be lowercase or
    uppercase. Lines beginning with a semicolon (;) are treated as
    comments.

    Figure E-1. DEF file directives documented in Appendix E
    --------------------------------------------------------

    CODE        Assigns characteristics to code segments
    DATA        Assigns characteristics to data segments
    DESCRIPTION Embeds text in executable file
    EXETYPE     Specifies host operating system
    EXPORTS     Names functions exported for dynamic linking by other
                programs
    HEAPSIZE    Specifies initial size of local heap (C programs only)
    IMPORTS     Names functions that will be dynamically linked at load
                time
    LIBRARY     Builds dynlink library or device driver
    NAME        Builds application program
    OLD         Specifies ordinal compatibility with previous version of
                dynlink library
    PROTMODE    Flags file as executable in protected mode only
    REALMODE    Allows file to be executed in real mode
    SEGMENTS    Assigns characteristics to selected segments
    STACKSIZE   Specifies size of stack used by primary thread
    STUB        Embeds MS-DOS-compatible program in new executable file

 For further information, refer to Appendix E, Module Definition File
 Syntax, in "Advanced OS/2 Programming" or Chapter 19, Using Module-
 Definition Files, in the "Microsoft FORTRAN CodeView and Utilities
 User's Guide," packaged with FORTRAN Version 5.00.


 70. Linker Error L4047 May Be Benign

 Product Version(s): 5.10    | 5.10
 Operating System:   MS-DOS  | OS/2
 Flags: ENDUSER |
 Last Modified: 18-APR-1990    ArticleIdent: Q59936

 The following linker error may be a benign error if it occurs with an
 application that links with the C Version 6.00 start-up code:

    L4047 - Multiple code segments in module of overlayed program
            incompatible with /CO

 This is a new error for LINK Version 5.10 and is to be expected.

 If an application is built with the C Version 6.00 run-time library,
 there is a second segment to hold floating-point math routines. This
 segment (EMULATOR_TEXT) does not have any CodeView information in it.
 However, from the linker's perspective, the extra segment MAY be an
 error and it is warning the user of such. In this case, it is a benign
 warning message.


 71. NODATA and pwords Parameters Reversed in EXPORT Statement Docs

 Product Version(s): 5.01.21 5.02 5.03 5.05 5.10 | 5.01.21 5.02 5.03 5.05 5.10
 Operating System:   MS-DOS                      | OS/2
 Flags: ENDUSER | docerr
 Last Modified: 25-MAY-1990    ArticleIdent: Q61605

 The EXPORT statement used in module definition (.DEF) files is
 incorrectly documented in several places with the last two parameters
 reversed. The "pwords" parameter should be the last parameter, but it
 is listed second from the end. The "NODATA" parameter is listed last,
 but should be second from the end. The correct EXPORT statement syntax
 is as follows:

    entryname [=internalname] [@ord[RESIDENTNAME]] [NODATA] [pwords]

 Note that the "pwords" parameter is listed as "iopl-parmwords" in some
 of the documentation.

 The documentation with the incorrect EXPORT statement syntax with
 reversed parameters is as follows:

 - The C version 6.00 online help for LINK under the EXPORT statement
   syntax

 - On Page 334 of "The Microsoft CodeView and Utilities User's
   Guide" for version 2.30 in Section 19.9, "The EXPORTS
   Statement" (shipped with FORTRAN 5.00 and BASIC PDS 7.00)

 - On Page Update-52 of "The Microsoft CodeView and Utilities
   Update" for version 2.20 in Section 7.8, "The EXPORTS
   Statement" (shipped with C 5.10, MASM 5.10, and Pascal 4.00)


 72. Fatal /nologo and /e Switch Interaction

 Product Version(s): 1.20   | 1.20
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | buglist1.20
 Last Modified: 22-JUN-1990    ArticleIdent: Q62375

 Using the /nologo switch in conjunction with /e switch can cause ILINK
 version 1.20 to fail. The problem will occur when an incremental link
 cannot be performed and the command specified by the /e switch is
 performed instead. If the /e switch is preceded anywhere on the
 command line by /nologo, then the link will fail.

 For example, the following command line

     ILINK /nologo /e "link hello;" hello.exe

 where hello.obj exists but hello.exe doesn't, will produce the
 following messages:

    Microsoft (R) Segmented-Executable Linker  Version 5.10
    Copyright (C) Microsoft Corp 1984-1990.  All rights reserved.

    LINK : fatal error L1089:  : cannot open response file
    ILINK : warning L4252: file '/e.exe' does not exist
    ILINK : performing full link
    ILINK : fatal error L1233: 'link' returned 2

 Placing the /nologo switch after the /e switch on the command line
 will alleviate the problem.

 Microsoft has confirmed this to be a problem with LINK version 1.20.
 We are researching this problem and will post new information here as
 it becomes available.


 73. L4050 Incorrectly Documented in Online Help

 Product Version(s): 5.10   | 5.10
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | docerr buglist5.10 S_PWB
 Last Modified: 24-JUL-1990    ArticleIdent: Q63235

 When linking a very small program with /EXEPACK, Microsoft LINKer
 version 5.10 sometimes gives the following error message:

    LINK: warning L4050: file not suitable for /EXEPACK; relink without

 The online Help documentation returns the following incorrect
 information:

    LINK warning L4050

    too many public symbols for sorting

    The linker uses the stack and all available memory in the near
    heap to sort public symbols for the /MAP option. If the number of
    public symbols exceeds the space available for them, this warning
    is issued and the symbols are not sorted in the map file but are
    listed in an arbitrary order.

    Reduce the number of symbols.

 The correct documentation for this error (except the number) is as
 follows and can be found in the online Help under L1114:

    Fatal LINK error L1114

    file not suitable for /EXEPACK; relink without

    For the linked program, the size of the packed load image plus
    packing overhead was larger than that of the unpacked load image.

    Relink without the /EXEPACK option.

 Because of its noncritical nature, this LINKer error was changed from
 its previous status of a fatal error to a simple warning in LINK
 version 5.10. The warning associated with L4050 in earlier versions of
 the LINKer will rarely appear in LINK 5.10, but if it does, it will
 have the number L4070.



 74. Parenthesis in Filename May Cause L1027: Unmatched Parenthesis

 Product Version(s): 3.x 4.06 4.07 5.01.21 5.03 5.05 5.10 | 5.01.21 5.03 5.05
 Operating System:   MS-DOS                               | OS/2
 Flags: ENDUSER |
 Last Modified: 10-JUL-1990    ArticleIdent: Q63624

 When linking object files into executable programs, the error L1027:
 "Unmatched left/right parenthesis" may be incorrectly generated for
 files that contain a parenthesis in the filename. This will only occur
 when the object module is in the current directory and either of the
 following conditions is true:

 1. If the object module being linked has a left parenthesis as the
    first character in its name, but NOT a right parenthesis as the last
    character.

 2. If an object filename has a right parenthesis as the last
    character in the name, but NOT a left parenthesis as the first.

 If the object module is NOT in the current directory, then the L1027
 error will occur only if the second condition above is true.

 This information applies to all versions of LINK.EXE that support
 overlays.

 Normally, parentheses are put around the names of one or more object
 modules when linking to inform LINK that the enclosed modules are to
 be in an overlay. Therefore, if a left (or right) parenthesis comes
 immediately before (or after) the name of an object module, LINK will
 expect a right (or left) parenthesis immediately after (or before) the
 name. If the parentheses do not match, a fatal L1027 error will be
 generated.

 For example, the following LINK command line causes an "Unmatched left
 parenthesis" error when the object module ABC.OBJ is in the current
 directory:

    link (abc;

 However, if ABC.OBJ is in a subdirectory, then the parenthesis is
 embedded in the middle of the path/filename string and no error is
 generated, as shown below:

    link temp\(abc;

 For the same reason, a file ABC).OBJ will NOT give an error if linked
 with the following line:

    link abc).obj;

 On the other hand, leaving off the .OBJ extension will result in the
 L1027 error:

    link abc);

 By the same reasoning, the placement of a left or right parenthesis in
 the middle of an object filename does not cause an error. The
 following three LINK lines all work correctly:

    link a(bc;
    link a()bc;
    link a)bc;


 75. ILINK 1.20 and 1.21 Are Not Backwards Compatible

 Product Version(s): 1.20 1.21 | 1.20 1.21
 Operating System:   MS-DOS    | OS/2
 Flags: ENDUSER |
 Last Modified: 24-OCT-1990    ArticleIdent: Q65817

 Using ILINK version 1.20 or 1.21, after doing a full link using a
 bound linker earlier than version 5.10 or a DOS linker earlier than
 version 4.10, causes the following message:

    ILINK : warning L4267: invalid .ILK file
    ILINK : performing full link

 If you use the ILINK version that came with the linker you are using,
 the .ILK file will be recognized correctly. ILINK versions 1.20 and
 1.21 are not "backwards compatible" and will not work correctly with
 earlier .ILK files.


 76. Unexpected DOS Error: 14 Generated by Using /INC

 Product Version(s): 5.10
 Operating System:   MS-DOS
 Flags: ENDUSER | s_quickc s_c
 Last Modified: 24-OCT-1990    ArticleIdent: Q66055

 Programs linked with the /INC (Prepare for Incremental Link) switch
 cause the following error if the program is executed using the
 Microsoft Windows version 3.00 Run command:

    Unexpected DOS error: 14.

 The Run command is located on the File menu in both the Windows
 Program Manager and the File Manager. If the program is run from a
 prompt in real DOS or in a DOS session of Windows 3.00, it executes
 properly.

 While this seems like a problem with the Microsoft Linker, Windows 3.0
 is actually at fault here. The use of the /INC switch causes the
 linker to create a segmented executable. When Windows attempts to run
 this .exe, it fails to recognize that it is a full screen application
 (ie: not a windows app) and subsequently tries to execute it as a
 Windows application. This bug has been entered into the Windows bug
 database and should be fixed in a future release.

 Note: This may appear to be a problem with QuickC and/or C version
 6.00 if the incremental link option is turned on. In fact, it is a
 linking issue, not a compiler issue.

 To workaround this problem, turn off the /INC switch.


 77. Response Filename Cannot Exceed 32 Characters

 Product Version(s): 5.01.21 5.03 5.05 | 5.01.21 5.03 5.05
 Operating System:   MS-DOS            | OS/2
 Flags: ENDUSER | buglist5.01.21 buglist5.03 buglist5.05 fixlist5.10
 Last Modified: 12-NOV-1990    ArticleIdent: Q66698

 When using a complete path specification for a response file with
 LINK.EXE versions 5.01.21, 5.03, and 5.05, there is a limit of 32
 characters that cannot be exceeded. The following example illustrates
 this:

    LINK @d:\c600\files\project\test\myfile.lnk

 This will fail with the following error:

    LINK : Fatal error L1089 : D:\C600\FILES\PROJECT\TEST\MYFIL :
         cannot open response file

 In LINK version 5.10, this limit has been increased to 255 characters.


 78. Linker Does Not Search Specified Drive for Libraries

 Product Version(s): 5.01.21 5.03 5.05 5.10 5.11  | 5.01.21 5.03 5.05 5.10 5.1
 Operating System:   MS-DOS                       | OS/2
 Flags: ENDUSER | buglist5.01.21 buglist5.03 buglist5.05 buglist5.10 buglist5.
 Last Modified: 12-NOV-1990    ArticleIdent: Q66699

 A library name can be embedded into an .OBJ module for the linker to
 search to resolve external references. This library name can either be
 the library name itself or the full path to the library. In the case
 of the full path to the library, the linker cannot handle a drive
 specifier.

 For example, with Microsoft C, the #pragma comment command is used to
 specify the library. If the following line is used

    #pragma comment (lib, "c:\C600\LIB\graphics.lib")

 the compiler will add a COMENT record to the .OBJ instructing the
 linker to search the C600\LIB subdirectory on drive C for the
 GRAPHICS.LIB library.

 The problem is that the linker will not search drive C but will
 instead search the default drive. When the library and/or path is not
 found, it will prompt for the path to the library. This is an error.

 Microsoft has confirmed this to be a problem in the Segmented Linker
 versions 5.01.21, 5.03, 5.05, 5.10, and 5.11. We are researching this
 problem and will post new information here as it becomes available.


 79. L2002 When Creating a Dynamic Link Library

 Product Version(s): 5.10 5.11
 Operating System:   OS/2
 Flags: ENDUSER | buglist5.10 buglist5.11
 Last Modified:  4-DEC-1990    ArticleIdent: Q67004

 The code sample below produces the following error when compiled and
 linked with the following switches:

 cl /c /Gs /Alfu /ML foo.c

 link foo.obj, foo.dll,,, foo.def;

 Error
 -----

    L2002: fix-up overflow at 2 in segment FOO_TEXT
     frm seg _DATA, tgt seg _DATA, tgt offset 0

 This error is produced when creating a dynamic link library and
 specifying _loadds on function entry (either with the /Au switch or
 the _loadds keyword). If each segment that comprises the default data
 segment is of zero length, the linker will return this error. In
 earlier linkers, the error wasn't generated.

 The following are three possible workarounds:

 1. If the function does not contain any static data, compile with the
    option /Aw (DS not reloaded on function entry) and/or remove the
    _loadds keyword from the function declaration.

 2. Turn on stack checking (compile without /Gs option).

 3. Declare data so at least one of the segments in DGROUP is not zero
    length.

    a. For _DATA, declare initialized global or static data.

    b. For _CONST, declare a constant in the program.

    c. For _BSS, declare uninitialized static data.

 Microsoft has confirmed this to be a problem in versions 5.10 and
 5.11. We are researching this problem and will post new information
 here as it becomes available.

 Sample Code
 -----------

 void foo(int i)
 {
    char c;

    c=i;
 }


 80. NOF Is Default for LINK, Not /F as C "Reference" States

 Product Version(s): 5.10   | 5.10
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | docerr S_C
 Last Modified:  4-JAN-1991    ArticleIdent: Q67085

 On pages 30 and 31 of the "Microsoft C Reference" manual shipped with
 C versions 6.00 and 6.00a, there are contradictory references to the
 far-call translation options available for LINK. On page 30 under the
 /F[ARCALLTRANSLATION] option, far-call translations are listed as
 being "turned on by default." On the other hand, on page 31 under the
 /NOF[ARCALLTRANSLATION] option, far-calls are listed as being "off by
 default."

 The statement on page 30 is the one that is incorrect because the
 correct default for far-call translations is "off." Far calls are done
 only when /F is explicitly specified to LINK.

 Note that when the CL command is used to invoke LINK, CL itself is
 responsible for passing the /F option to the linker.


 81. EXE Checksum Incorrect If linked with /CO or /E

 Product Version(s): 3.xx 4.0x 4.10 5.0x 5.10 5.13 | 5.0x 5.10 5.13
 Operating System:   MS-DOS                        | OS/2
 Flags: ENDUSER |
 Last Modified:  6-FEB-1991    ArticleIdent: Q67795

 According to "The MS-DOS Encyclopedia," a DOS .EXE file contains a
 checksum value in the .EXE file header. This checksum value should
 allow the summation of all words in the .EXE file to equal FFFFh.
 However, if you use the /Exepack or the /COdeview options when linking
 a program, the checksum value will not be calculated correctly.
 Current versions of MS-DOS ignore this checksum so this will not cause
 any noticeable problems.

 Sample Code:
 ------------

 #include <stdio.h>
 #include <stdlib.h>

 main (int argc, char * argv[])
 {
    FILE * fp;
    unsigned int nxt= 0, sum= 0;
    unsigned char bl, bh;

    if (argc != 2)
       exit (-1);
    if ((fp= fopen (argv[1], "rb"))== NULL)
       exit (-1);
    while (! feof(fp))
    {
       bl= fgetc (fp);
       if (! feof(fp))
          bh= fgetc (fp);
       else
          {
          bl= 0;
          bh= 0;
          }
       sum= sum+ nxt;
       nxt= (unsigned int) bh* 256U+ (unsigned int) bl;
    }
    nxt&= 0xFF;
    sum+= nxt;
    printf ("sum = %X\n", sum);
 }


 82. L1008: "Segment Limit Too High" May Be Caused by Missing Colon

 Product Version(s): 3.x 4.06 4.07 5.01.21 5.03 5.05 5.10 | 5.01.21 5.03 5.05
 Operating System:   MS-DOS                               | OS/2
 Flags: ENDUSER |
 Last Modified: 17-DEC-1990    ArticleIdent: Q46733

 When linking, the following error may be caused by incorrectly
 specifying the parameters for the /SE switch on the link command line
 with the colon:

    LINK : fatal error L1008: SE: segment limit set too high

 To generate the error, link using the /SE switch, then insert a space
 and the number of segments for the linker to use, such as the
 following:

    LINK /SE 1024

 The correct syntax for the /SE option is with a colon separating the
 switch from the numeric argument as follows:

    LINK /SE:1024


 83. The Purpose of Module Definition Files

 Product Version(s): 5.01.21 5.02 5.03 5.05 5.10 5.13 | 5.01.21 5.02 5.03 5.05
 Operating System:   MS-DOS                           | OS/2
 Flags: ENDUSER |
 Last Modified: 17-DEC-1990    ArticleIdent: Q27134

 Module-definition files (.DEF) are used by LINK when building Windows
 and OS/2 programs and dynamic-link libraries (DLLs). A .DEF file
 describes the name, size, format, functions, and segments of an
 application or DLL.

 A module-definition file contains one or more module statements. Each
 module statement defines an attribute of the executable file. The
 module statements and the attributes they define are listed below:

 Statement         Attribute
 ---------         ---------

 NAME              Name and type of application
 LIBRARY           Name of dynamic-link library
 DESCRIPTION       One-line description of the module
 CODE              Default attributes for code segments
 DATA              Default attributes for data segments
 SEGMENTS          Attributes for specific segments
 STACKSIZE         Local-stack size, in bytes
 EXPORTS           Exported functions
 IMPORTS           Imported functions
 STUB              Adds a DOS Version 3.x executable file to the beginning
                   of the module, usually to terminate the program when
                   run in real mode
 HEAPSIZE          Local-heap size, in bytes
 PROTMODE          Specifies that the module runs only in OS/2 protected
                   mode
 REALMODE          Specifies that the module is for real-mode Windows.
 OLD               Preserves export ordinal information from a previous
                   version of the library

 The following rules govern the use of these statements in a module-
 definitions file:

 1. If you use either a NAME or a LIBRARY statement, it must precede
    all other statements in the module-definition file.

 2. You can include source-level comments in the module-definition
    file, by beginning a line with a semicolon (;). The OS/2 utilities
    ignore each such comment line.

 3. Module-definition keywords (such as NAME, LIBRARY, and SEGMENTS)
    must be entered in uppercase letters.

 For more information, refer to the utility reference or online help
 that accompanied your particular compiler or assembler.


 84. Working Around Link Error "L1064: Out of Memory"

 Product Version(s): 5.03 5.05 5.10 5.13 | 5.03 5.05 5.10 5.13
 Operating System:   MS-DOS              | OS/2
 Flags: ENDUSER |
 Last Modified: 17-DEC-1990    ArticleIdent: Q45718

 The linker error "L1064: Out Of Memory" is new with LINK version 5.03,
 which was first shipped to individuals using IMSL libraries with
 FORTRAN 4.10, and was then shipped with FORTRAN 5.00. The description
 of the error is as follows (from the "Microsoft FORTRAN, Microsoft
 CodeView and Utilities User's Guide"):

    The linker was not able to allocate enough memory from the
    operating system to link the program. On OS/2 try increasing the
    swap space. Otherwise, reduce the size of the program in terms of
    code, data, and symbols. On OS/2, consider splitting the program
    into dynalink libraries.

 In DOS, the only ways to work around the error are the following:

 1. Remove any memory-resident software or device drivers that may be
    limiting the available memory of the machine.

 2. Reduce the program size, as described above.

 In OS/2, the easiest way to work around the error is to increase the
 swap space, as follows:

 1. Close other screen groups and remove other processes from
    memory to free up both RAM and swap space on the swap drive.

 2. Create more free disk space on the drive that is pointed to by
    the SWAPPATH setting in the CONFIG.SYS file. (Delete or move files,
    or change the setting to a drive with more free space.)

 3. Possibly DECREASE the swap value set by the SWAPPATH variable (do
    this with caution -- read below).

 Explanation of the SWAPPATH Setting in CONFIG.SYS
 -------------------------------------------------

 Swapping must be enabled via the MEMMAN setting in CONFIG.SYS for the
 SWAPPATH setting to be acknowledged at all (usually "MEMMAN=SWAP" or
 "MEMMAN=SWAP,MOVE").

 The default setting for SWAPPATH after setting up OS/2 is usually as
 follows:

    SWAPPATH=C:\OS2\SYSTEM 512

 The drive setting indicates the drive and directory where the space
 for the swapper file will be allocated. If no SWAPPATH variable is
 set, the swapper file is allocated in the root directory on the boot
 drive. The number that follows indicates the amount of free space
 which must be left on this drive when the swapper file has grown to
 its maximum size. (This number, by itself, says nothing about the
 maximum size of the swapper file.) Given the settings above, the
 maximum size of the swapper file can be easily calculated by the
 following:

    (free space on Drive C) - (SWAPPATH value) = max. swap file size

 Therefore, increasing the SWAPPATH value DECREASES the amount of space
 available for the swapper file.

 The swapper value can be decreased, and the system will allow values
 down to 0 (zero). However, because OS/2 does time-slicing between
 processes and may need to write to the disk in question, decreasing
 the swapper value below 512K (the system default) is not recommended.
 This workaround should be used only if you have the value set to
 greater than 512K (the range of valid values is from 0 to 32,767). If
 this is the case, set the SWAPPATH value to 512 and reboot the
 machine. If this method does not solve the problem, you must clear
 space on the hard disk by deleting or moving files.


 85. Patches Available for Running Utilities Under Novell NetWare

 Product Version(s): 5.10
 Operating System:   MS-DOS
 Flags: ENDUSER | appnote SC0381.ARC s_codeview s_pwb s_c
 Last Modified:  6-FEB-1991    ArticleIdent: Q68659

 When LINK version 5.10 is run under a Novell network, LINK may fail
 with the following error:

    L1085: cannot open temporary file

 In addition, the C version 6.00 Setup program (SETUP.EXE), the
 Programmer's WorkBench (PWB) for DOS versions 1.00 and 1.10, and
 real-mode CodeView (CV.EXE) versions 3.00, 3.10, and 3.11 may all hang
 when run under some Novell NetWare software.

 These problems are directly related to the network software, but may
 be corrected with a set of patch files available from Microsoft as an
 application note titled "Network Patches for Utilities" (SC0381).
 Application notes can be obtained by calling Microsoft Product Support
 Services at (206) 637-7096.

 The "Network Patches for Utilities" application note can also be found
 in the Software/Data Library by searching on the keyword SC0381, the Q
 number of this article, or S12898. SC0381 was archived using the
 PKware file-compression utility.

 The following is the complete text of the application note, which
 includes the details of the problems mentioned above:

 ======================================================================
                     Network Patches for Utilities
 ======================================================================

 The enclosed Network Patches for Microsoft Utilities disk contains the
 following five files:

    README.DOC
    CVPATCH.EXE
    PWBPATCH.EXE
    SETUPFIX.EXE
    LINK.EXE

 These files solve conflicts with certain network setups. Please be
 sure to make backup copies of the original files.

 Network Patch Files
 -------------------

 When run under certain network software, some Microsoft utilities may
 hang. The enclosed patch files are designed to correct these problems
 for CodeView versions 3.00, 3.10, and 3.11; the Programmer's WorkBench
 (PWB) versions 1.00 and 1.10; and the C 6.00 Setup program.

 To install the patches, first copy the patch files (PWBPATCH.EXE,
 CVPATCH.EXE, and SETUPFIX.EXE) to the directories where you have
 installed PWB, CodeView, and Setup, respectively. Each patch assumes
 that the utility file it is to patch is in the same directory.

 Run SETUPFIX.EXE to patch SETUP.EXE. The original file will be saved
 as SETUP.BAK. Run CVPATCH.EXE to patch CV.EXE. The original file will
 be saved as CV.BAK. Run PWBPATCH.EXE to patch PWBED.EXE. The original
 file will be saved as PWBED.BAK. The patched utilities should run free
 of network interference.

 Microsoft LINK Version 5.13
 ---------------------------

 LINK version 5.13 includes code to work around another problem that
 sometimes occurs when running on a network. On large projects, the
 linker needs to open some temporary files to work around DOS memory
 limitations. LINK version 5.10 (supplied with C 6.00) will sometimes
 fail in its attempts to open a temporary file when run under certain
 network software.

 The problem actually lies in the network software, not the linker.
 When the network is loaded, the return value from an open call
 sometimes gets corrupted. When the call fails, it is because an "Out
 of handles" error (EMFILE) is returned as a "No such file or
 directory" error (ENOENT). If this occurs, LINK 5.10 halts with an
 "L1085: cannot open temporary file" error.

 LINK 5.13 includes a change to correct for the above situation (even
 though the problem is in the network software). When LINK version 5.13
 receives an ENOENT error on a failed open call, it will still try to
 free some file handles and reopen the temporary file, regardless of
 the error returned.

 To make the correction, locate LINK version 5.10 and replace it with
 LINK version 5.13 from the enclosed disk. Again, be sure to save a
 backup copy of the original file (LINK 5.10).


 86. L2025 LINK Error May Be Caused by Conflicting Library Routines

 Product Version(s): 3.x 4.06 4.07 5.0x 5.10 5.13 | 5.01.21 5.02 5.03 5.10 5.1
 Operating System:   MS-DOS                       | OS/2
 Flags: ENDUSER | s_lib
 Last Modified: 24-JAN-1991    ArticleIdent: Q44465

 All variables and routines in a module within a library will be linked
 into a program when any single variable or routine residing in that
 module is referenced. This can cause the following linker error if two
 or more modules contain definitions for the same symbol:

    L2025  symbol defined more than once

 For example, in the diagram below, module1 contains routines "a", "b",
 and "c". The module2 contains routines "c", "d", and "e". When main()
 references "a" and "e", the linker links module1 and module2 from the
 library. This results in "c" being defined twice. Removing "c" from
 one of the modules, recompiling the module, and replacing the module
 in the library with the LIB utility operator "-+" will prevent "c"
 from being multiply defined.

                         +-----------+
                         |           |
                         | calls "a" |
                         | calls "e" |
                       / |           | \
                      /  +-----------+  \
                     /       main()      \
                    v                     v
                +-------+             +-------+
                |   a   |             |   c   |
                |   b   |             |   d   |
                |   c   |             |   e   |
                |       |             |       |
                +-------+             +-------+
                 module1               module2

 For each routine you want to be linked separately, compile a separate
 object file and add it to the library.






 Microsoft `M' Editor
 =============================================================================


 1. How to Put Microsoft Editor (M or MEP) into 43-Line Mode

 Product Version(s): 1.00   | 1.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified:  1-SEP-1988    ArticleIdent: Q28580

 To use the Microsoft Editor (M.EXE or MEP.EXE) in EGA 43-line mode,
 the TOOLS.INI file must be modified to include the following
 statement:

 HEIGHT:41

 (The number 41 is used because the last two lines are used by the
 editor as status/error lines. See Page 59 of the "Microsoft Editor for
 MS OS/2 and MS-DOS: User's Guide".)

 Once the TOOLS.INI is modified, the editor must be re-initialized.
 This process is done with the Initialize command. The default key
 stroke for this command is SHIFT+F8. Appendix A lists the values for
 the other .INI files provided with the editor. The following example
 demonstrates this process:

 1. Load TOOLS.INI.
 2. Modify TOOLS.INI.
 3. Save the file (ARG ARG SETFILE or leave and re-enter).
 4. Use the Initialize command (SHIFT+F8).

 After the initialization, the changes in the TOOLS.INI become active
 and the 43-line mode is in use.

 M.EXE runs in MS-DOS real mode, and MEP.EXE runs in OS/2 protected
 mode.


 2. Creating Macros for the Microsoft Editor

 Product Version(s): 1.00   | 1.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified:  1-SEP-1988    ArticleIdent: Q23051

 Macros for the Microsoft Editor are sequences of editor functions. For
 example, a macro to delete the word to the right of the cursor is
 defined as follows:

 worddelete:=arg meta pword sdelete

 The above macro is named "worddelete". To associate "worddelete" with
 a particular keystroke, the following command is needed:

 worddelete:ALT+W

 The macro "worddelete" is now bound to the keystroke "ALT+W". Note
 that the macro definition (i.e., ":=") resembles a Pascal assignment
 statement, but the keybinding uses a colon to delimit the macro name
 from the key to which it is assigned. The following is another
 example:

 filestamp:=curfilenam curfileext " - " curdate " " curtime
 filestamp:ALT+S

 This macro creates a file-time stamp that contains the filename, the
 current date, and the current time; it is assigned to the keystroke
 "ALT+S".


 3. File Size Limitations for the Microsoft Editor

 Product Version(s): 1.00   | 1.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | TAR62237
 Last Modified: 29-AUG-1988    ArticleIdent: Q23609

 Question:

 What is the largest file the Microsoft Editor can load?

 Response:

 The size of the file is controlled by the operating system, not by
 the editor. The editor will read in a file of any number of bytes;
 however, you are limited by the temporary file space.

 The size of the drive pointed to by the TMP variable is the limiting
 factor. Because TMP often points to a (relatively small) RAM drive,
 such as VDISK or MS-RAMDRIVE, this is the most common file size
 limitation.

 A safe rule-of-thumb is that your TMP drive may need to be up to
 two times the size of the file being edited.

 The maximum number of lines a file can contain is 0x7FFFFFFF, but you
 will run out of disk space before you have too many lines.

 Both MS-DOS and OS/2 currently limit disk size (hence, file size)
 to 64K sectors, which normally is 32 megabytes.


 4. Unassigning Predefined Keys

 Product Version(s): 1.00   | 1.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | TAR62300
 Last Modified:  1-SEP-1988    ArticleIdent: Q23754

 The following are two ways to unassign a predefined key:

 1. Assign the key to a different function.
 2. Assign the key to the "unassigned" function.

 If ALT+A currently is assigned to the ARG function, you can assign
 it to another function by putting the following line in your
 TOOLS.INI file:

 NewFunct:ALT+A

 If you don't want ALT+A to be assigned to any function, place the following
 line in your TOOLS.INI file:

 Unassigned:ALT+A.


 5. Error C1015 "Can't Open Include File" with MEP

 Product Version(s): 1.00
 Operating System:   OS/2
 Flags: ENDUSER | S_C buglist1.00
 Last Modified:  2-NOV-1988    ArticleIdent: Q35140

 The example program below generates the following error:

 Error C1015 "Can't open include file"

 The program must be compiled with one of the output-file switches
 (such as /Fc) or through a make file to generate this error.

 The include file os2.h opens two other include files: os2def.h and
 bse.h. The bse.h include file, in turn, opens three other include
 files: bsedos.h, bsesub.h, and bseerr.h.

 Microsoft has confirmed this to be a problem in Version 1.00. We are
 researching this problem and will post new information as it becomes
 available.

 The compiler attempts to open the last include file and generates the
 C1015 error. The total file count at this point is 15, as follows:

  1. stdin
  2. stdout
  3. stdprn
  4. stderror
  5. stdaux
  6. MEP
  7. source
  8. listing file
  9. os2.h
 10. os2 def.h
 11. bse.h
 12. bsedos.h
 13. bsesub.h
 14. bseerr.h
 15. tmp file

 The following sample code demonstrates the problem:

 #define INCL_BASE
 #include <os2.h>

 void main (void)
 void main (void)
 {
 }



 6. Maximum Number of Defined Macros Allowed in TOOLS.INI File

 Product Version(s): 1.00   | 1.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | TAR63148
 Last Modified: 17-MAY-1988    ArticleIdent: Q24696

 Question:
    Is there a maximum number of macros, predefined and user-defined,
 allowed in the TOOLS.INI file?

 Response:
    The maximum number of defined macros allowed is 1024.


 7. BRIEF TOOLS.INI File Assigns Two Commands to F5 in M.EXE

 Product Version(s): 1.00    | 1.00
 Operating System:   MS-DOS  | OS/2
 Flags: ENDUSER |
 Last Modified:  1-SEP-1988    ArticleIdent: Q30474

 Problem:

 After I configure the Microsoft M.EXE Editor in the BRIEF mode and
 invoke Psearch (F5 key), I receive the following error message:

 "Invalid argument."

 However, Msearch (ALT+F5) functions correctly.

 Response:

 The BRIEF TOOLS.INI file assigns two commands to F5. The first
 occurrence in the file is for Psearch and the second is for
 DeleteWindow.

 To correct the problem, one of the commands should be mapped to a
 different key. Make sure the new key is not already in use.

 The following is an example of the incorrect portion of the
 BRIEF.INI file:

    ; TOOLS.INI file for BRIEF(tm) configuration
    [M]
           .
           .
           .
    Psearch:F5
           .
           .
           .
    ; WINDOWS
    ;
    ; Delete Current Window is F5
    DeleteWindow:=meta window
    DeleteWindow:F5
    ;
    ;
    ;
    ; BRIEF is a trademark of UnderWare, INC.


 8. Assigning Key Sequence to ENTER and BACKSPACE Keys

 Product Version(s): 1.00   | 1.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified: 29-AUG-1988    ArticleIdent: Q25407

 Functions can be assigned to the ENTER and BKSP (BACKSPACE) keys in
 the TOOLS.INI file, as in the following example:

 emacsnewl:enter
 emacscdel:bksp

 Consult Chapter 6 of the "Microsoft Editor User's Guide," titled
 "Function Assignments and Macros."


 9. CALLTREE Ignores Conditional Compilation Statements in Editor

 Product Version(s): 1.00   | 1.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | S_C H_MASM
 Last Modified: 17-MAY-1989    ArticleIdent: Q44417

 The CALLTREE utility provided with the Microsoft Editor can be used to
 produce a graphical call-tree listing of a project. The following
 command line is an example of this utility. This command line creates
 a file called CALLS.TXT showing the relationship of the functions
 found in the four C source files shown below:

    calltree /c calls.txt main.c sub1.c sub2.c sub3.c

 If any of the files use conditional compilation directives, these are
 disregarded by CALLTREE and any functions that would not have been
 called appear in the call listing. An example of code that produces a
 misleading call listing is shown below. Although only one set of calls
 is compiled, both sets show up in the file produced by CALLTREE.

     void main( void )
     {
     #ifdef DEBUG
         dshow();
         ddone();
     #else
         fshow();
         fdone();
     #endif
     }

 To avoid this situation, a preprocessor listing should be produced
 using the /P switch with CL, and CALLTREE should then be run on the
 resultant file.

 This is a limitation of the utility. CALLTREE is meant to be a
 general-purpose tool for C and assembly programs, and is not designed
 to do any parsing or syntax checking.


 10. Microsoft Editor Fails to Find TOOLS.INI Using DOS Version 2.x

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 20-OCT-1988    ArticleIdent: Q28590

 Problem:

 When running the M.EXE editor under DOS Versions 2.x, the editor does
 not find the TOOLS.INI file. The error reported is "Unable to Read
 TOOLS.INI[]".

 The following demonstrates the problem:

 1. Rename QUICK.INI to TOOLS.INI.
 2. Set the environment variable INIT to the directory c:\mytools
    as follows:

    SET INIT=c:\mytools

 3. Load the M.EXE editor. It will come up with default settings,
    instead of reading TOOLS.INI.

 When running DOS Version 3.20 on an IBM PC AT, M.EXE correctly finds
 the TOOLS.INI file.

 Response:

 M.EXE and MEP.EXE use their startup name to find the right section in
 TOOLS.INI. For example, if you rename the editor to Z, it will look
 for [z] instead of [m] in the editor's section in TOOLS.INI.

 This process occurs in all cases except under DOS Versions 2.x. Under
 any 2.x version of DOS, the name of your program is not available, and
 instead, the compiler provides the arbitrary name "C".

 To work around this limitation in DOS Versions 2.x, change the
 editor's tagged section in TOOLS.INI file to use the tag [c] instead
 of [m]. If it is necessary to share files with DOS Versions 3.x
 systems, the editor's section in TOOLS.INI can be tagged [m c].

 The editor uses the same method to name the following, where * is
 replaced by the editor name or by "C" under DOS Versions 2.x:

 1. The virtual memory file, *-XXXX.VM
 2. The history-and-state file, *.TMP
 3. The compiler message file, *.MSG


 11. Using Full Pathnames to Compile Programs with M or MEP

 Product Version(s): 1.00   | 1.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | TAR75085
 Last Modified: 20-OCT-1988    ArticleIdent: Q29150

 The full pathname of a file is not transferred to the compiler when an
 ARG COMPILE is executed in the Microsoft Editor for MS-DOS and OS/2.
 The following is an example:

 1. Invoke M.EXE as follows:

 M \c5\source\test.c

 2. Compile the program with ARG COMPILE. (The default value is
    ALT+A SHIFT+F3). The following line is displayed:

    CL /c /Zep /D LINT_ARGS test.c

    The full pathname is not given.

 If you plan on compiling from other directories, you should define
 the compile command using the %|F option. The default option %s uses
 only the filename. For example, the TOOLS.INI file could be modified
 as follows to get the default compile with the full pathname:

 extmake:c cl /c /Zep /D LINT_ARGS %|F

 You also can select portions of the full pathname, and use the name
 more than once, as in the following example:

 %d|F - obtains the drive (and colon)
 %p|F - obtains the path
 %f|F - obtains the filename (no extension)
 %e|F - obtains the extension

 You can combine the "dpfe" any way you wish, as in the following:

 %dpf|F.xyz

 This combination produces the drive, path, and filename, with the
 extension .XYZ added to the filename.


 12. Editor "User's Guide" C-Extension Sample Generates Warnings

 Product Version(s): 1.00   | 1.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified: 12-JUL-1988    ArticleIdent: Q29730

 Problem:
     When I compile the sample program on Page 85 of the "Microsoft
 Editor for MS OS/2 and MS-DOS: User's Guide," I get two warning
 messages.
    These warning messages are generated on the following two sections
 of the sample program:

    1. struct swiDesc swiTable [] = {
             { NULL, NULL, NULL }
        };

    2. struct cmdDesc cmdTable [] = {
             { "Upper", Upper, 0, BOXSTR | TEXTARG },
             { NULL, NULL, NULL, NULL }
        };

 Response:
   These warnings will not cause a problem. You can, however, make the
 following two changes:

    1. struct swiDesc swiTable [] = {
             { NULL, NULL, 0 }
        };

    2. struct cmdDesc cmdTable [] = {
             { "Upper", Upper, 0, BOXSTR | TEXTARG },
             { NULL, NULL, 0, 0 }
        };


 13. Missing Semicolon on Line 17 of Example on Page 85 in Manual

 Product Version(s): 1.00   | 1.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | docerr
 Last Modified: 29-AUG-1988    ArticleIdent: Q29731

    On Page 85 of the "Microsoft Editor for MS OS/2 and MS-DOS: User's
 Guide," there is a missing semicolon on line 17.
    The following line is incorrect:

    cfile = FileNameToHandle("", NULL)

    It should read as follows:

    cfile = FileNameToHandle("", NULL);


 14. M.EXE Editor Macro to Join Current Line with Next Line

 Product Version(s): 1.00    | 1.00
 Operating System:   MS-DOS  | OS/2
 Flags: ENDUSER |
 Last Modified: 29-AUG-1988    ArticleIdent: Q30030

    The following macro will join the current line with the following
 line, leaving one space between the last character on the current line
 and the first character of the next line.
    Place the following three lines in the [M] and/or [MEP] section(s)
 of your TOOLS.INI file, or enter them from the keyboard using the
 ASSIGN function (ALT+= in the default keyboard setup):

    ;Macro to join current line with next line.
        join:=endline right arg down begline sdelete
        join:alt+j

    The following is a description of how the join macro works:

    1. Endline moves one place beyond the last character on the current
       line.
    2. Right moves one character further, to insert a space.
    3. arg introduces the argument to the next command (in this case,
       sdelete).
    4. down begline moves to the first character on the next line.

    This process defines a Streamarg for the command sdelete (S stands
 for Stream).
    Note that sdelete should be used, not ldelete, because the down
 begline sequence would have defined either a Linearg or a Boxarg,
 neither of which would join the lines.
    Use sdelete because it closes the stream of characters and/or white
 space between the starting cursor position and the ending cursor
 position.


 15. Microsoft Editor Macro Moves Text with TAB Key

 Product Version(s): 1.00   | 1.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified:  6-JAN-1989    ArticleIdent: Q30033

 The TAB key only moves the cursor. It does not move both the cursor
 and the text under the cursor (as it does in QuickC, Word, and many
 other editors).

 To move text and the cursor, put the following macro in your TOOLS.INI
 file in the [M] and/or [MEP] section(s):

    ;Macro to tab with insertion, as in QuickC and Word
        emacstab:=arg tab sinsert tab
        emacstab:ctrl+tab

 The "emacstab" macro (there is no significance to the name other than
 its similarity to M.EXE's EMACSNEWL and EMACSDEL functions) is invoked
 by pressing CTRL+TAB.

 Note: assigning this macro to CTRL+TAB will only function on
 enhanced-style keyboards. Older-style keyboards must use another set
 of keys for this macro assignment. On the older keyboards, assigning
 this macro to CTRL+TAB causes the macro to be ignored.

 The emacstab macro functions as follows:

 1. The Arg command introduces the argument (in this case, a
    "stream" arg).

 2. The Tab command moves you one tab stop to the right.

 3. The Sinsert command moves the highlighted text over to the tab
    stop.

 This macro leaves your cursor back where it started, so one more TAB
 moves your cursor to the right (on top of the shifted text).


 16. C Extension to Make Psearch Prompt for an Input in M.EXE

 Product Version(s): 1.00
 Operating System:   OS/2
 Flags: ENDUSER |
 Last Modified: 23-MAY-1988    ArticleIdent: Q30285

 Question:
    I wish to emulate the Brief Psearch (Plus Search) with the M.EXE
 editor. I want Psearch to prompt me to enter a search string. Can this
 be done with a macro or do I have to use a Microsoft C extension?

 Response:
     This emulation cannot be done with macros. However, it can be done
 with Microsoft C extensions.
     The following is an example of how to do so in a Microsoft C
 extension:

     1. Use DoMessage() to output a string saying something similar to
 the following:

     "Please enter the search string:"

     2. Use KbUnHook() to disable M.EXE's "logical keyboard." This
 gives you the "focus" of the keyboard so that keyboard input is no
 longer read by the editor, thus freeing you to input a string from the
 user.
     3. Parse the keyboard input and then process it appropriately by
 invoking the Psearch function.
     4. Use KbHook() to reenable the logical keyboard in M.

     The following is an alternate method:

     Use "ReadChar()" instead of "KbUnHook()" and "KbHook()."
 (Mentioned in steps two and four above.)

     For more information on the functions available for writing C
 extensions, please read the files EXT.DOC and EXT.H that are included
 with the Microsoft Editor Version 1.00.
     For general information on programming C extensions, please
 consult Chapter 8 of the "Microsoft Editor User's Guide."
     Appendix A of the "Microsoft Editor User's Guide" provides a
 comprehensive list of editing functions such as Psearch.
     Psearch searches forward for the previously defined string or
 pattern. Msearch (Minus Search) searches backward for the previously
 defined string or pattern.


 17. Debug Shown on M.EXE Help Screen Is Not a Supported Switch

 Product Version(s): 1.00   | 1.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | docerr
 Last Modified: 15-JUN-1988    ArticleIdent: Q30365

    The Debug numeric switch that appears in the information file of
 the help screen in the Microsoft Editor Version 1.00 has not been
 implemented.
    There is no function associated with Debug.


 18. M.EXE C Extensions Documented in UTILITY.DOC, Not README.DOC

 Product Version(s): 1.00
 Operating System:   OS/2
 Flags: ENDUSER | docerr
 Last Modified: 26-MAY-1988    ArticleIdent: Q30534

    Page 70 of the "Microsoft Editor User's Guide" incorrectly states
 the following:

    "To create a successful C extension, you need to follow these
 guidelines:
        1. Check the README.DOC file to see what functions you can call
 from the standard C run-time library."

    Contrary to the above manual statement, C extensions are documented
 in UTILITY.DOC on the release disk, not in the README.DOC.



 19. Making Assignments to PLUS, MINUS and PRINT SCREEN Keys

 Product Version(s): 1.00   | 1.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | tar66615
 Last Modified:  1-SEP-1988    ArticleIdent: Q31485

 It is possible to make key assignments to the PLUS, MINUS, and
 PRINT SCREEN keys on the numeric keypad.

 For more information on function assignments, macros, and keystrokes,
 consult section 6.2.1 of "The Microsoft Editor User's Guide."


 20. How to Load a C Extension that Is Not in Current Directory

 Product Version(s): 1.00
 Operating System:   OS/2
 Flags: ENDUSER | TAR75933 docerr
 Last Modified:  8-JUN-1988    ArticleIdent: Q30826

    Page 84 of the "Microsoft Editor for OS/2 and MS-DOS User's Guide"
 incorrectly infers that the M.EXE editor will search for a C-extension
 module along the DOS PATH under MS-DOS or OS/2 real mode when you
 place the following statement in the TOOLS.INI file:

    load:myext.exe

    To search for a C-extension module along the DOS PATH, you must
 instead use the following load switch syntax in the TOOLS.INI file:

    load:{$ENVAR: | dos path}filename.ext

 where you have the option of using $ENVAR: (a DOS environment
 variable) or an explicit directory path specification.
    You can prefix your filename with $PATH: or $INIT:. For example,
 "$PATH:filename.ext" means the "filename.ext" is to be found in the
 directories in the DOS PATH. This format is valid in any filename
 context. The following example will go to the STDIO.H file that
 actually is being used by the compiler:

    <arg> "$INCLUDE:stdio.h" <setfile>

    Also, when operating under OS/2, $ENVAR:, the explicit DOS path,
 and the extension on the filename are ignored. Instead, filename.DLL
 is searched for in your LIBPATH. Please note that LIBPATH under OS/2
 is not an environment variable. LIBPATH is a directive in the
 CONFIG.OS2 file.
    The following are examples of using the load switch in TOOLS.INI:

    ; load 'my.ext' from the current directory.
    ; Under OS/2, load my.dll from LIBPATH.
    load:my.ext

    ; load 'your.ext' from either the current directory or one
    ; of the directories on path
    ; Under OS/2, load 'your.dll' from LIBPATH
    load:$PATH:your.ext

    ; load 'c:\init\ourext'.
    ; Under OS/2, load 'ourext.dll' from LIBPATH
    load:c:\init\ourext



 21. An Example Where a Protect Mode C Extension Will Not Load

 Product Version(s): 1.00
 Operating System:   OS/2
 Flags: ENDUSER | TAR76121 TAR76251
 Last Modified:  8-JUN-1988    ArticleIdent: Q30827

 Problem:
    I am trying to create an extension to the MEP.EXE editor. I am
 unable to get the editor to load my C extension. To simplify things I
 tried to get the editor to load the sample SKEL; however, I was
 unsuccessful. I receive the following error messages when loading:

    "cannot load skel - invalid argument"
    "skel is an illegal setting"

    My LIBPATH is c:\os2\dll and skel.dll is placed there. If skel.dll
 is not in my libpath I would get the error "no such file or
 directory". My MAKE and DEF files for SKEL are as follows:

 SKEL MAKE FILE
 #
 # Makefile for the MEP Editor Extensions
 #
 SYS=\os2\dll

 .c.obj:
  cl -c -Gs -Asfu -G2 -Lp $*.c

 .obj.dll:
  link  /NOI /NOD exthdrp.obj $*.obj,$*.dll,nul.map,,$*.def;

 skel.obj:    skel.c skel

 skel.dll:    skel.obj skel.def

 $(SYS)\skel.dll:  skel.dll
        copy skel.dll $(SYS)

 SKEL DEF FILE

 LIBRARY  SKEL

 EXPORTS
  _ModInfo
  SKEL

 Response:
    The extension is not loaded because the DEF file is incorrect. The
 file should be as follows:

 SKEL.DEF:
    LIBRARY

    EXPORTS
            _ModInfo
            EntryPoint

    This file should be used with all the extensions that are written.
 It need not be modified.



 22. Tags Let You Use the Same TOOLS.INI File for M and MEP

 Product Version(s): 1.00
 Operating System:   OS/2
 Flags: ENDUSER | TAR76127
 Last Modified:  8-JUN-1988    ArticleIdent: Q30828

 Question:
    I have the same commands for M and for MEP. I want to load the
 QUICKHELP utility if I am running OS/2. However, in my TOOLS.INI file,
 if I put in the following information, MEP never reads the rest of
 the TOOL.INI file:

    [mep]
     load:qhmep
    [m mep]
     rest of the commands
     .
     .

    How should I do this without making two (almost identical) files,
 one for [m] and one for [mep]?

 Response:
    Through the use of tags, it is possible to use the same TOOLS.INI
 file in both protect mode and real mode/DOS. The tag must specify the
 program name along with the version of the operating system as in the
 following example:

    [m-3.2]    => MS-DOS 3.2
    [m-10.0]   => OS/2 1.0 protect mode
    [m-10.0R]  => OS/2 1.0 real mode
    [m-10.10]  => OS/2 1.1 protect mode
    [m-10.10R] => OS/2 1.1 real mode

    The following change should be made to your TOOLS.INI file:

        [m mep]
                 commands that are non operating system dependent
             .
             .
             .

        [mep-10.0]
             load:qhmep

    The number used in the tag is the major and minor version number of
 of the operating system being used. Under OS/2 this information can be
 found by calling the API routine DosGetVersion. The call can be made
 from any language that supports the use of the API,including C Version
 5.10, MASM Version 5.10, FORTRAN Version 4.10, PASCAL Version 4.10,
 and BASCOM Version 6.00. Under DOS, this information is displayed with
 the DOS VER command.


 23. Setting TMPSAV in TOOLS.INI file; M.TMP Cannot Be Suppressed

 Product Version(s): 1.00
 Operating System:   OS/2
 Flags: ENDUSER | TAR76606
 Last Modified:  8-JUN-1988    ArticleIdent: Q30829

 Question:
    How do I get the Microsoft Editor (both ME and MEP) to not create
 and use the M.TMP to record past editing sessions?
    I have tried setting the switch tmpsave:0 in the TOOLS.INI file,
 but this does not solve the problem. Is there some other switch I have
 not set properly or a way to exit without creating M.TMP?

 Response:
    There is no way to prevent the creation of the temporary file.
    The TMPSAV switch is used to control the maximum number of files
 about which information is kept between editing sessions. This
 information includes the cursor position and window layouts.
    When you edit one of these files again, the screen starts up as you
 left it. The default value is 20. If TMPSAV is set to 0, it causes all
 files to be saved. All other numeric values refer to the number of
 files that will be saved. The /t option specifies that any files
 edited are temporary; they are not saved in the M.TMP file.



 24. Protected-Mode C Extensions Fail with "Protection Fault"

 Product Version(s): 1.00 | 1.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | docerr
 Last Modified: 29-AUG-1988    ArticleIdent: Q31009

 Problem:
    I am writing C extensions for the protected mode of OS/2. All my
 extensions fail with a general-protection fault. The sample program on
 Page 85 of the "Microsoft Editor for MS OS/2 and MS-DOS: User's Guide"
 also fails.

 Response:
    Page 78 of the "Microsoft Editor for MS OS/2 and MS-DOS: User's
 Guide" incorrectly states that the second argument is a NULL pointer.
    The programs are crashing because the incorrect value is being
 passed to the FileNameToHandle routine. This routine requires a
 pointer to a null string, not a null pointer.
    For example, the following statement

    cfile=FileNameTohandle("",NULL);

 should read as follows:

    cfile=FileNameTohandle("","");


 25. Two Toned Colors in <assign> Pseudo File Can Occur

 Product Version(s): 1.02    | 1.02
 Operating System:   MS-DOS  | OS/2
 Flags: ENDUSER | buglist1.02
 Last Modified: 29-JAN-1990    ArticleIdent: Q58029

 The <assign> pseudo file can consist of lines in blocks that alternate
 in color starting at the middle of the file. This appears as if you've
 changed multiple editor options, which have just been activated, when
 no changes were actually made. This does not affect the way M.EXE (or
 MEP.EXE) operates.

 To see the blocks of alternating color, follow the steps below:

 1. Invoke the editor.

 2. Press ALT+A <ASSIGN> F2, which implies ARG <ASSIGN> SETFILE.

 3. Press ALT+BACKSPACE, which implies UNDO.

 4. Press F9 ALT+BACKSPACE, which implies META UNDO.

 5. Page down until you see the colored blocks.

 Microsoft has confirmed this to be a problem with the Microsoft Editor
 Version 1.02. We are researching this problem and will post new
 information here as it becomes available.


 26. Return Type for ReadCmd Is PSWI, Not PCMD

 Product Version(s): 1.00 | 1.00
 Operating System:   OS/2 | MS-DOS
 Flags: ENDUSER | docerr
 Last Modified: 12-JAN-1989    ArticleIdent: Q31143

 Page 7 of the EXT.DOC file, located in the SOURCE\ME\EXT directory of
 the Microsoft C Optimizing Compiler Version 5.10, incorrectly lists
 the return type for the ReadCmd command as being PCMD.

 The correct return type is PSWI, which is documented in the EXT.H
 file.


 27. MEP Crashes OS/2 when Switching from Real-Mode Screen Group

 Product Version(s): 1.00   | 1.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |  TAR75546 TAR76522
 Last Modified: 28-OCT-1988    ArticleIdent: Q31144

 When running in OS/2 protected mode, the system may crash when
 switching between protected mode and real mode and using the ALT+ESC
 sequence. It may take several iterations of ALT+ESC before the failure
 occurs.

 The system crashes when switching from the real-mode session into a
 protected-mode session that is running MEP. When the system crash
 occurs, the following message appears:

     TRAP 000D

     <register contents>

     The system detected an internal processing error
     at location # 3430:0590
     Exception while in kernel mode

     The system is stopped

 This is not a problem in MEP; it is a problem in OS/2.

 You can work around this problem by not running MEP in the original
 ("default") protected-mode screen group. Instead, start a second
 protected-mode screen group and run MEP there. To move to the second
 protected-mode screen group, do the following:

 1. Press ALT+ESC from real mode to get to the original
    protected-mode screen group.

 2. Press ALT+ESC again to get to the MEP screen group.

 Running MEP in a second screen group prevents you from switching
 directly from real mode into the MEP screen group.

 Another workaround for this problem is to use the CTRL+ESC hotkey
 rather than the ALT+ESC command to leave the real-mode screen group.
 The CTRL+C hotkey brings you back to the program selector. Once
 there, you can select the next screen group by using the mouse or
 cursor keys.


 28. "Unable to Read TOOLS.INI" Message Appears in OS/2 with MEP

 Product Version(s): 1.00
 Operating System:   OS/2
 Flags: ENDUSER |
 Last Modified:  8-JUN-1988    ArticleIdent: Q31155

     MEP.EXE, the OS/2 version of the Microsoft editor, will give the
 following message when the INITIALIZE function is invoked (i.e.,
 SHIFT-F8 in the default keyboard setup):

    "Unable to read TOOLS.INI"

    This message will appear if the editor's name is left as MEP while
 the TOOLS.INI tag for the editor is labeled [M]. The two names must
 match.
    To correct the problem, either rename the editor to M, or label the
 tag [MEP].
    The tag can be set to [M MEP] if you wish to use the same TOOLS.INI
 settings for both real-mode and protected-mode versions of the editor.


 29. Purpose of ECH.EXE with the Microsoft Editor

 Product Version(s): 1.00
 Operating System:   OS/2
 Flags: ENDUSER |
 Last Modified:  8-JUN-1988    ArticleIdent: Q31280

    ECH.EXE is used by the editor to generate the list of files you
 receive when you do <arg> "*.C" <setfile>.



 30. NOSOFTCR Parameter in TOOLS.INI Disables Auto Indentation

 Product Version(s): 1.00
 Operating System:   OS/2
 Flags: ENDUSER | tar69375
 Last Modified: 14-JUN-1988    ArticleIdent: Q31486

    The automatic indentation at the beginning of lines can be
 disabled.
    The NOSOFTCR parameter prohibits the Microsoft Editor from making
 indentation "guesses." NOSOFTCR is specified in the TOOLS.INI file, as
 follows:

    nosoftcr:



 31. Features Supported when Editing TextArgs in Microsoft Editor

 Product Version(s): 1.00
 Operating System:   OS/2
 Flags: ENDUSER | tar69726
 Last Modified:  6-JAN-1989    ArticleIdent: Q31487

 When editing TextArgs, not all editing features are supported. The
 following features are supported:

 QUOTE, INSERT, SDELETE, RIGHT, LEFT, UP, DOWN, HOME, and END

 When an unsupported feature is entered, the editor will beep. Macros
 may be used, but they can contain only supported features.

 The END key allows you to find the length of the search/replace
 string; pressing ARG clears the entire string.


 32. UTILITY.DOC: Filetab Switch Expands Tabs

 Product Version(s): 1.00 | 1.00
 Operating System:   OS/2 | MS-DOS
 Flags: ENDUSER | tar71845
 Last Modified: 16-JUN-1988    ArticleIdent: Q31488

    Information about the filetab switch can be found in the
 UTILITY.DOC file that comes with the Microsoft BASIC Compiler Version
 6.00, the Microsoft C Compiler Version 5.10, the Microsoft FORTRAN
 Compiler Version 4.10 and the README.DOC for Microsoft MASM Version
 5.10.
    The filetab switch is a numeric switch that determines how the
 editor translates tabs when loading a file into memory. The value of
 the switch gives the number of spaces associated with each tab column.
    For example, the setting "filetab:4" assumes a tab column every four
 positions on each line of a file.
    Every time the editor finds a tab character in a file, it loads the
 buffer with the number of spaces necessary to get to the next tab
 column. Depending on the value of the entab switch, the editor also
 uses the filetab switch to determine how to convert spaces into tabs
 when writing a file.
    The default value of filetab is eight (8).



 33. Tabs Expanded to Eight Spaces; Filetab Switch Changes Spacing

 Product Version(s): 1.00   | 1.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | Tar70793
 Last Modified:  1-SEP-1988    ArticleIdent: Q31489

 Question:

 Why are tabs expanded to eight spaces even though I set the tabstop
 variable and the entab switch?

 Response:

 Neither the tabstops or the entab switch affect how tabs are expanded
 when the file is read. The filetab switch is used to determine how
 many spaces to expand each tab. For example, "filetab:4" will expand
 each tab in the file to four spaces.

 The entab switch controls how the editor converts multiple spaces
 into tabs when a line is changed or a file is saved. The default is
 one (1). The following chart shows different values and their
 meanings:

 Value   Meaning

 0       Tabs are not used to represent white space.
 1       All multiple spaces outside of quoted strings
         are converted to tabs (default).
 2       All multiple spaces are converted to tabs.

 Tabstops control the number of spaces between each logical tabstop
 for the editor. The default is four (4).


 34. Resizing Windows

 Product Version(s): 1.00   | 1.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | tar63957
 Last Modified:  1-SEP-1988    ArticleIdent: Q31490

 It is not possible to directly resize windows in the Microsoft Editor.
 A window can only be opened or closed. To resize a window, it must be
 closed and then reopened. Direct resizing of windows is not currently
 possible.

 This feature is under review and will be considered for inclusion in a
 future release.


 35. Parentheses Matching in Microsoft Editor; Arg Meta PBal

 Product Version(s): 1.00
 Operating System:   OS/2
 Flags: ENDUSER | tar63957
 Last Modified: 31-OCT-1988    ArticleIdent: Q31491

 The Microsoft Editor has the capability of matching parentheses
 without altering the current file. Meta PBal prevents the file from
 being edited while balancing parentheses and brackets.

 The following are various other options for Pbal:

 1. Pbal: Scan backwards through the file, balancing parentheses and
    brackets. The first unbalanced one is highlighted when found. If it
    is found and is not visible, the editor displays the matching line,
    with the highlighted matching character. Note that the search does
    not include the current cursor position, and that the scan only
    looks for more left brackets or parentheses than right, not just an
    unequal amount.

 2. Arg Pbal: Performs similarly to Pbal, except that it scans
    forward in the file and looks for more right brackets or parentheses
    than left.

 3. Arg Meta Pbal: Performs similarly to Arg Pbal except that the
    file is not updated.


 36. Editing Nonexisting Files with the Microsoft Editor

 Product Version(s): 1.00
 Operating System:   OS/2
 Flags: ENDUSER | tar62913
 Last Modified: 16-JUN-1988    ArticleIdent: Q31492

    If the Microsoft Editor is invoked to edit a nonexisting file, it
 creates a file with a length of zero in the DELETED directory in
 addition to creating a new file. This occurs with the backup switch
 set to "undel" (the default) in the TOOLS.INI file.
    This behavior is expected and is program design for the product.
 When the Microsoft Editor is invoked to edit an existing file, the
 previous version is moved to the DELETED directory.
    The EXP command allows you to remove this file, and all other files
 from the DELETED directory.



 37. Macro to Toggle HOME Key

 Product Version(s): 1.00
 Operating System:   OS/2
 Flags: ENDUSER | tar66615
 Last Modified: 12-JAN-1989    ArticleIdent: Q31493

 You can create a macro to do the following:

 1. Press HOME key (cursor goes to beginning of line).

 2. Press HOME key again (cursor goes to top of window).

 3. Press HOME key again (cursor goes to top of buffer).

 This technique usually is used to create a toggle key, but it is
 equally applicable to the desired three-step toggle. The technique is
 as follows:

 home1:= begline arg "home2:f10" assign
 home2:= home arg "home3:f10" assign
 home3:= mark arg "home1:f10" assign
 home1:f10

 After following this procedure, the F10 key will toggle among begline,
 home, and mark.


 38. Inserting Time and Date into Files

 Product Version(s): 1.00   | 1.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified:  1-MAY-1989    ArticleIdent: Q40176

 To write a macro to insert the time and date into your file, use the
 following insert commands:

    Command     Action

    Curdate     Inserts current date
    Curday      Inserts current day of the week
    Curfile     Inserts current filename
    Curfileext  Inserts current file extension
    Curfilenam  Inserts base name of current file
    Curtime     Inserts current time
    Curuser     Inserts name specified in USER environment variable

 The following macro can be inserted into your TOOLS.INI to insert the
 filename, time, and date:

 ;Macro for time and date.
     Header:= Curfilenam tab Curtime tab Curdate
     Header:Alt+H


 39. Macro to Enter Form Feed or Control Characters in Editor

 Product Version(s): 1.00 | 1.00
 Operating System:   DOS  | OS/2
 Flags: ENDUSER | tar62237
 Last Modified:  1-NOV-1988    ArticleIdent: Q31495

 The form-feed characters and control characters below can be entered
 in a file being edited by the Microsoft Editor.

 The following macro inserts a linefeed, (CTRL+L), and a newline, and
 binds it to the F6 key. To enter a CTRL+L, use the Graphic assignment
 on Page 48 of the "Microsoft Editor User's Guide" when editing your
 TOOLS.INI file:

 graphic:ctrl+l

 FFM:="L" newline   ; Instead of the L shown here, insert a CTRL+L
 FFM:F6             ; with the quote function "CTRL+P CTRL+L"

 The macro below allows you to enter control key values. The
 following line binds "quote" to F5. Quote allows you to enter any key
 as input (i.e., control key values, etc). This means if you type "F5"
 followed by a "CTRL+X", you will see a "\030" instead of "arg":

 quote:F5.


 40. "Unsupported Video Mode" When Loading Microsoft Editor

 Product Version(s): 1.00 1.02 | 1.00 1.02
 Operating System:   MS-DOS    | OS/2
 Flags: ENDUSER |
 Last Modified: 28-JUL-1989    ArticleIdent: Q31498

 It is possible when loading M.EXE or MEP.EXE to receive an
 "Unsupported video mode, please change modes and restart" error
 message. This message may mean that the hardware is not supported.

 Graphics cards supported in this situation include IBM's CGA, EGA,
 MCGA, MDPA, and VGA and the Hercules card. An example of an
 unsupported system is the 8514 video adapter.

 In MS-DOS (or OS/2 real mode), the Microsoft Editor (M) supports the
 8514/A graphics card, but in OS/2 protected mode, MEP Version 1.00
 does not support this graphics card. A "video mode not supported"
 error message occurs in protected mode.

 The Microsoft Editor Version 1.02 supports the 8514/A graphics card in
 both real and protected mode. This version is currently available with
 FORTRAN 5.00.


 41. Environment Variables Used by the Microsoft Editor

 Product Version(s): 1.00
 Operating System:   OS/2
 Flags: ENDUSER |
 Last Modified: 16-JUN-1988    ArticleIdent: Q31547

    The Microsoft Editor uses the following environment variables:

    1. TMP: This directory stores all temporary files.
    2. INIT: This directory stores the TOOLS.INI, M.TMP, and temporary
 files if TMP is not set.

    Please note, if neither environment variable is set, all temporary
 files except M.TMP are written to the root directory of the disk being
 used. M.TMP is written to the current directory.
    The environment variables usually are set in the AUTOEXEC.BAT file.
 For example the following lines can be placed in the AUTOEXEC.BAT
 file:

     SET INIT=c:\init
     SET TMP=c:\temp

    Also, if the TMP environment variable ends with a semicolon, the
 temporary files (i.e., swapping files) will not be created. The editor
 will try to use the semicolon in the name of the file that is created.


 42. Editor Utilities DOS Version 2.x and 8086/8 Corrections

 Product Version(s): 1.00
 Operating System:   OS/2
 Flags: ENDUSER | appnote
 Last Modified:  6-JAN-1989    ArticleIdent: Q31801

 The following files are included in this application note:

    MEGREP.EXE, RM.EXE, UNDEL.EXE, ECH.EXE and EXP.EXE.

 These files are replacements for the original utilities that were
 shipped with the Microsoft Editor Version 1.00. They have been updated
 to correct two specific problems only; they do not include any additional
 functionality over the originals.

 These files correct the problem of embedded 286 instructions that
 prevented the programs from correctly running on 8086 and 8088
 machines (the machines would hang). The files also have been updated
 to correct problems when used with DOS Version 2.x.

 To install the files, copy the files from the appnote disk over the
 files (of the same names) that are installed on the machine.

 This application note can be obtained by calling Microsoft Product
 Support Services at (206) 454-2030.


 43. Preventing Generation of Tabs in the Edited Disk Files

 Product Version(s): 1.00   | 1.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified: 25-JUL-1988    ArticleIdent: Q32033

    It is impossible to search for a tab or replace a string with a tab
 in the M editor.
    When a file is being edited, there are no tab characters in the
 file. When the M editor reads from disk to memory, it converts tabs to
 spaces. When it writes from memory to disk, it converts spaces to tabs
 (unless you set the ENTAB switch to 0).
    This may create problems when devices other than your machine
 access the file. For example, if you edit a source file on your IBM PC
 with the M editor, then try to compile the source file on a mainframe,
 the source file may not compile because of the tabs in the disk file
 created by the M editor.
    The solution is to set ENTAB to 0 in the TOOLS.INI file; this value
 will prevent tabs from being used to represent white space when
 writing from memory to disk.
    For more information on the ENTAB switch, please refer to Table 7.2
 on Page 59 of the "Microsoft Editor User's Guide."


 44. M Hangs on Tandy 2000 with MS-DOS Version 2.11

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified:  1-SEP-1988    ArticleIdent: Q32052

 M, the Microsoft Editor for MS-DOS, hangs when run on a Tandy 2000
 computer running MS-DOS Version 2.11.

 M does not support the Tandy 2000. There is no workaround to this
 incompatibility.


 45. Scrolling One Line at a Time

 Product Version(s): 1.00   | 1.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |  buglist1.00
 Last Modified: 20-OCT-1988    ArticleIdent: Q32053

 Problem:

 The editor jumps seven lines at a time when I Scroll off the top or
 bottom of the screen. I want it to Scroll one line at a time, but it
 Scrolls four lines at a time when I set VSCROLL to 1.

 Response:

 Hike and Scroll are designed to be independent functions; however,
 they are incorrectly tied together.

 Microsoft has confirmed this to be a problem in Version 1.00 of the
 editor. We are researching this problem and will post new information
 as it becomes available.

 A workaround to this problem is to set both VSCROLL and HIKE to 1 in
 your TOOLS.INI file in the [M] section, as in the following example:

 [M]
     hike:1
     vscroll:1


 46. Installing M with Msetup

 Product Version(s): 1.00    | 1.00
 Operating System:   MS-DOS  | OS/2
 Flags: ENDUSER | h_fortran
 Last Modified: 19-JUL-1988    ArticleIdent: Q32094

 Question:
    The FORTRAN Version 4.10 setup program did not install the
 Microsoft Editor. I could not find any documentation on how to use
 msetup in the UTILITIES.DOC. How do I set up the Editor?

 Response:
    To run the msetup program, place the "Microsoft Editor" disk in
 Drive A and type "msetup". A help screen will be displayed showing
 the syntax for using msetup. An example of running msetup is as
 follows:

    A:>msetup c: \m \init \binp

    This procedure will install the M Editor and M tools (MEGREP, ECH,
 UNDEL, etc.) in the M directory, TOOLS.INI in the INIT directory, and
 MEP in a BINP directory. If you do not specify any directories, the
 program will use default directories. It will show these default
 directories on the screen and prompt you for any changes. These
 directories must be created before running msetup; otherwise, it will
 not be installed correctly.
    Please note that when the msetup prompts you for the type of
 emulation to use for the TOOLS.INI file, a TOOLS.INI file will not be
 created if you type a "0" for the default tools (the defaults are
 already built into Editor). If any of the other emulations are used,
 msetup will rename the appropriate file to TOOLS.INI and install it.


 47. Exit Does Not Save Files when NoAutosave Is Set

 Product Version(s): 1.00   | 1.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified: 31-OCT-1988    ArticleIdent: Q32095

 When the boolean switch Autosave is disabled (by setting it to
 NoAutosave), a file will not be saved when exiting the editor.

 As documented on Page 61 of the "Microsoft Editor User's Guide," when
 the Autosave switch is turned on, the current file is saved when the
 user switches away from it. When Autosave is off (NoAutosave), the
 file must be explicitly saved when desired; this can be done by
 entering Arg Arg Setfile (ALT+A ALT+A F2 in the default keyboard
 setup).


 48. Arg *.* Setfile: "Bad Command or Filename" Error

 Product Version(s): 1.00   | 1.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | tar78150
 Last Modified: 29-AUG-1988    ArticleIdent: Q32224

    Entering the command Arg *.* Setfile causes M to display a list of
 all files in the current directory.
    ECH.EXE is a utility used to generate the list of files for ARG
 textarg SETFILE. If this utility cannot be found, you will receive a
 message saying "Bad command or filename." ECH.EXE must be located in a
 directory on the path.


 49. Using the SHORTNAMES Switch

 Product Version(s): 1.00   | 1.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | tar78150
 Last Modified: 31-MAR-1989    ArticleIdent: Q32225

 SHORTNAMES is a boolean switch. When it is set (the default), if you
 type <arg> "foo" <setfile>, you will be sent to the first file in your
 history list with the base name "foo". You do not have to specify the
 full pathname for a file in another directory. If there is no
 d:\path\foo.xxx anywhere in your file history, you only get foo.

 If you have a file "foo" in your current directory, SHORTNAMES still
 tries to find a file in your history list first. The history of files
 is stored in M.TMP. The number of files saved is determined by the
 TMPSAV switch.

 To disable this feature, set noshortnames: in your TOOLS.INI file.

 To avoid this behavior without changing the switch value, include a
 period in the path specification. For example, enter <arg> "foo."
 <setfile>, which will look only in the current directory. The presence
 of any path character (".", etc.) disables the SHORTNAMES feature for
 the file being referenced.


 50. Cancel Clears the Type-Ahead Buffer

 Product Version(s): 1.00   | 1.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | tar75933
 Last Modified: 19-JUL-1988    ArticleIdent: Q32226

    The Cancel command clears the type-ahead buffer. This is a feature
 of the editor and is not considered a problem.
    Cancel is mapped to the ESC key in the default keyboard setup.


 51. Loading a TAGGED Section Reinitializes the Editor

 Product Version(s): 1.00   | 1.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | buglist1.00 tar76973
 Last Modified: 29-AUG-1988    ArticleIdent: Q32228

 When a TAGGED section is initialized (<arg> "section name"
 <initialize>), all current macros are destroyed before
 reinitialization.

 The curdate, curtime, etc., macros are reset, your extmake: settings
 are set to the default, and the OS-dependent and video-dependent
 sections of TOOLS.INI are read in. If you type <initialize>, the main
 section is read in place of the TAGGED section.

 Microsoft has confirmed this to be a problem in Version 1.00. We
 are researching this problem and will post new information as it
 becomes available.



 52. The extmake Compile Switch Is Case Sensitive

 Product Version(s): 1.00   | 1.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | buglist1.00
 Last Modified:  1-MAY-1989    ArticleIdent: Q32242

 The following extmake entry will be ignored, causing the default
 command line to be used:

 extmake:C cl /c /Zi /Od %s

 Microsoft has confirmed this to be a problem in Version 1.00. We
 are researching this problem and will post new information as it
 becomes available.

 Although there is no case sensitivity for the extmake switch name, the
 extension specified ("C" in this example) must be in lowercase. If the
 extension is not in lowercase, the help screen will show a separate
 entry for that extension, as follows:

    C   cl /c /Zi /Od %s
    c   cl /c /Zep /D LINT_ARGS %s

 The second command line will be used when compiling a C program.


 53. Loading Tagged Sections in OS/2 Version 1.10

 Product Version(s): 1.00
 Operating System:   OS/2
 Flags: ENDUSER | docerr
 Last Modified: 29-AUG-1988    ArticleIdent: Q33348

 Problem:

 I have followed the instructions on Page 64 of the "Microsoft Editor
 User's Guide" for loading tagged sections in OS/2, but the editor
 never loads this section. My TOOLS.INI file has a tag titled [M MEP]
 containing assignments for both protected and real modes and a tag
 titled [M-10.0] for OS/2 protected-mode assignments. I am running
 Microsoft OS/2 Version 1.10.

 Response:

 Your [M-10.0] tag is not loaded in OS/2 Version 1.10 because [M-10.0]
 means OS/2 Version 1.00. The version number should be changed from
 10.0 to 10.10; your tag should be [M-10.10]. If you want the tag to
 work correctly for both OS/2 Versions 1.00 and 1.10, create a tag
 titled [M-10.0 M-10.10].

 This information is not contained in the "Microsoft Editor User's
 Guide."


 54. C.TMP Files in Current Directory

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified:  2-SEP-1988    ArticleIdent: Q34251

 Question:

 Every time I edit a file with the Microsoft Editor, I receive a C.TMP
 file in that directory. I am using DOS Version 2.10. Why is it
 creating this file?

 Response:

 The C.TMP file is where the editor keeps its information about
 previous files that have been edited. This file normally is called
 M.TMP; however, due to a limitation of DOS Versions 2.x, the editor
 believes its name is C rather than M.

 The files are placed in the directory where the file was edited
 because unless the INIT environment variable is set, the .TMP file is
 written to the current directory.

 When using M on DOS Versions 2.x, change the tag field of the TOOLS.INI
 from [M] to [C] and set the INIT environment variable to the directory
 that contains TOOLS.INI.



 55. How to Perform Spell Checking in M

 Product Version(s): 1.00   | 1.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified: 29-AUG-1988    ArticleIdent: Q34274

 Question:
    Does the Microsoft Editor have any spell checking capabilities?

 Response:
    The M editor does not have built-in spell checking. If you have a
 separate spell-check program you can write a macro to invoke it on
 your current file.
    For example, you could use the spell checker that comes with
 Microsoft Word Version 4.00 by doing the following:

     [M]
         ...
         Spell:=Arg "spell-am " Curfile Shell
         Spell:ALT+S

    The macro works as follows:

    1. Arg introduces an argument to the shell command.
    2. "spell-am" is the name of the spell-check utility
       included in Word Version 4.00.
    3. Curfile is the name of the current file you are editing. Note
       the space at the end of "spell-am "; this space is needed so the
       argument you pass to Shell is "spell-am YourCurrentFile" instead
       of "spell-amYourCurrentFile".
    4. The Shell command invokes COMMAND.COM and passes it the
       spell-am command. When spell-am completes its spell-check,
       it will return to the editor.


 56. Changing Height Switch Not Sufficient to Change Video Modes

 Product Version(s): 1.00   | 1.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified:  1-SEP-1988    ArticleIdent: Q34411

 Microsoft Editor does not immediately change video modes (CGA/EGA/VGA)
 when changing the numeric switch HEIGHT: to either 23, 41, or 48 in the
 TOOLS.INI file.

 For the new height setting to take effect, one of the following must
 be done:

 1. The INITIALIZE function can be invoked to force the editor to
    update its settings based on the switch values in TOOLS.INI. This
    will reset the video-display configuration. (INITIALIZE is ALT+F10
    for Quick and EPSILON emulation, SHIFT+F10 for BRIEF emulation, or
    SHIFT+F8 for the default emulation).

 2. The assignment can be made directly to the editor by invoking
    <arg> height:41 <assign>. In the default keyboard configuration,
    this would be ALT+A "height:41" ALT+=.

 3. While editing the "height:41" line in TOOLS.INI, move to the
    beginning of the line and enter <arg> <assign>, which is ALT+A
    ALT+= in the default keyboard assignments.

 The video mode is stored in the M.TMP file in the directory pointed to
 by the TMP environment variable; if TMP is not set, M.TMP is placed in
 the current default directory. Invoking the INITIALIZE function causes
 M to reset the settings in M.TMP based on the settings in TOOLS.INI.


 57. Accessing Switch Values in C Extensions

 Product Version(s): 1.00   | 1.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified:  2-SEP-1988    ArticleIdent: Q35025

 There is no direct function call to access switch values defined in
 the editor, such as rmargin or vscroll or hike, in your C Extension.
 However, you can find the value by using fExecute() to switch to the
 help file, then use the psearch or msearch functions to locate
 rmargin. At the end of that line you will find the value associated
 with rmargin.

 The following is an example:

 fExecute("Arg \"<assign>\" Setfile");  /* switch to "<assign>" file   */
 fExecute("Mark");                      /* go to beginning of it       */
 fExecute("Arg \"rmargin\" Psearch");   /* search for "rmargin"        */
 fExecute("Pword");                     /* get the number after it     */

 You also can use the GetLine() function to read through the <assign>
 file; this method involves more coding, but it will run faster than
 using fExecute() to execute macros.


 58. Passing Textargs to M with the /E Switch

 Product Version(s): 1.00   | 1.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified:  1-SEP-1988    ArticleIdent: Q35028

 Question:

 How can I pass textargs to the editor using the /e command-line
 switch?

 Response:

 Type in the name of the function you want the editor to execute. If
 you want to use more than one function, enclose the functions in
 double-quotation marks. If your functions require arguments, use the C
 syntax for specifying quotation marks within strings, i.e., the
 backslash escape character (\). Thus, a double-quotation mark within
 a string is specified with \".

 The following examples demonstrate various methods of passing
 command-line arguments to M:

 m /e psearch myfile

 This example invokes the Microsoft Editor on the file "myfile",
 passing it the command "psearch" to be executed immediately. The
 psearch will search for whatever string was last specified (in the
 search buffer).

 m /e "mark psearch" myfile

 This example again edits "myfile", but this time it passes two
 commands to M: "mark" and "psearch". The Mark command goes to the
 beginning of the file, and psearch searches forward for an occurrence
 of the search-string (which must have been specified in a previous
 search).

 m /e "arg \"search string\" psearch" myfile

 This example passes the editor the following string:

 "arg "search string" psearch"

 The \" characters are a C escape sequence that evaluates to a
 double-quotation mark ("); as a result, the entire string has a string
 embedded in it. The effect of this command is to tell the editor to
 search for the literal text "search string".

 m /e "arg \"\\\"a quoted search string\\\"\" psearch" myfile

 This is the most complicated case of argument passing. It
 passes the following string to the editor:

 "arg "\"a quoted search string\"" psearch"

 This command searches for the QUOTED literal text ""a quoted search
 string"".  The "\" and \"" are necessary to cause M itself to postpone
 evaluation of the double-quotation marks until actual search time.


 59. A Workaround for the MGREP Problem in M/MEP Version 1.02

 Product Version(s): 1.02   | 1.02
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified: 29-JAN-1991    ArticleIdent: Q68386

 In the M/MEP Editor version 1.02, there is a problem in the MGREP
 function; it will fail to find some matches to the query in the file.
 (This is due to certain regular-expression matches failing when they
 shouldn't.) Below is a macro that will use the MEGREP.EXE utility to
 search for a string, and return the results in the compile window. The
 benefits are:

 1. It should be faster, especially under OS/2.

 2. If run under OS/2, it will be a background process enabling you
    to continue working.

 Macro Code
 ----------

 Add the following to your TOOLS.INI file. You can then assign it to a
 keystroke, if desired:

 megreplist:="*.c *.h"
 mg1:=copy arg "<megrep>" setfile mark emacsnewl mark paste begline
 mg2:="arg arg \"megrep \\\"" endline "\\\" " megreplist
 mg3:=" \" compile" begline arg endline execute setfile
 megrep:= mg1 mg2 mg3

 The following is another option, which avoids using an extra
 pseudo-file:

 megreplist:="*.c *.h"
 mg:= copy arg "<clipboard>" setfile            \
      begfile "megrep \"" endline "\" " megreplist  \
      begline arg arg endline compile setfile

 Notes
 -----

 1. The first macro is in three parts due to line-length limits of the
    knowledge base; the macro could be just one line. The second macro
    uses line continuation characters to achieve the same result as
    breaking up the first macro.

 2. The macro assumes that all files on disk are up to date.


 60. MHELP Driver Not Completely Compatible with QuickC Help Files

 Product Version(s): 1.02   | 1.02
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | s_quickc buglist1.02
 Last Modified:  5-MAR-1990    ArticleIdent: Q58603

 The MHELP driver cannot process some cross-references inherent to the
 QuickC Versions 2.00 and 2.01 help files. Results range from the MHELP
 message "Cannot Process Cross Reference," to hanging the computer. In
 general, direct reference to a QuickC help file from within the editor
 is fine. However, moving around within the help file system using the
 built-in cross-references produces unpredictable results.

 The MHELP driver seems unable to access unformatted text files such as
 header, source, and DOC files. For example, QuickC allows you to
 access both the README.DOC file and QuickC header files from within
 the help system. Attempting these feats from within M leads to one of
 the following problems:

 1. "Cannot Process Cross Reference," if file not found.

 2. DOS will hang the machine if the file is found.

 3. OS/2 may cause a SYS 1943 protection violation if the file is
    found.

 The M editor also cannot use the <back> menu option to access a
 previously viewed help file. Attempting this yields the message
 "Cannot Process Cross Reference" at the bottom of the screen. The
 syntax of the <back> cross-reference in unencrypted help form is
 help file to access the previous help screen. This undocumented
 feature is not allowed in MHELP.

 Certain series of cross references cause sporadic errors. You should
 be careful to avoid internal cross-referencing within the QC help
 files. The problem can be shown with the following sequence using the
 QuickC and QuickAssembler help files from within the M Editor.

    <arg> seg <F1> <TAB> <RETURN> <TAB> <RETURN> <TAB>

 This example reaches the help-contents window via the "seg" example
 program. Upon reaching this point, it may hang DOS with the run-time
 error R6003 or R6001. OS/2 displays a black box in the upper-right
 corner of the screen and may crash at this point.

 Microsoft has confirmed this to be a problem with the M Editor Version
 1.02. We are researching this problem and will post new information
 here as it becomes available.


 61. Compiling in M Produces No .OBJ File

 Product Version(s): 1.00   | 1.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified: 20-OCT-1988    ArticleIdent: Q35233

 If compilation from within the editor gives no .OBJ file when the
 same compilation outside of M succeeds in creating an object module,
 check the CONFIG.SYS files setting.

 In one case, a user had "files=25" while running under DOS Version
 3.20, which doesn't support a file setting greater than 20. If files
 exceed 20, DOS uses its default of eight files. When the user set
 "files=20" an .OBJ was created from a compilation within M.


 62. Creating Windows in M and MEP

 Product Version(s): 1.00   | 1.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified:  1-MAY-1989    ArticleIdent: Q35235

 Question:

 How can I create multiple windows and edit multiple files with the
 Microsoft Editor?

 Response:

 Both horizontal and vertical windows can be created. You can have up
 to eight windows on the screen.

 To create a horizontal window, position the cursor on the screen where
 you would like the window break and press ARG WINDOW (ALT+A F6 in the
 default).

 This process creates a new window with a copy of the file you were
 currently editing. You then can load a different file into that window
 (ARG SETFILE ALT+A F2).

 To create a vertical window, position the cursor on the screen where
 you would like the window break and press ARG ARG WINDOW (ALT+A ALT+A
 F6 in the default). You then can load a different file into the
 window.

 Once you have several windows on the screen you can move around from
 window to window using the WINDOW command (F6 in the default setup).

 See also section 4.6 of the "Microsoft Editor User's Guide."

 Note: Each window must have a minimum of five lines and 10 columns to be
 created.


 63. M Does Not Respond to Changes in the Height Switch

 Product Version(s): 1.00   | 1.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified: 31-MAR-1989    ArticleIdent: Q35252

 The Microsoft Editor does not change video modes (EGA/VGA) when
 changing the numeric switch height to either 23, 41, or 48 in the
 TOOLS.INI file.

 The INITIALIZE function must be invoked to reset the video display
 configuration. (INITIALIZE = ALT+F10 for Quick and EPSILON emulation,
 SHIFT+F10 for BRIEF emulation, or SHIFT+F8 for the default emulation).

 The video mode also is stored in the M.TMP file in the directory
 pointed to by the INIT environmental variable or the current default
 directory.


 64. Toggling Display Modes: 25-, 43-, and 50-Row Modes

 Product Version(s): 1.00   | 1.00
 Operating System:   MS-DOS | MS-DOS
 Flags: ENDUSER |
 Last Modified: 14-NOV-1988    ArticleIdent: Q37628

 The following Microsoft Editor macro allows you to toggle the EGA
 display between 25-row mode and 43-row mode by pressing ALT+E:

 ;Macro to toggle 25/43 line EGA modes
     to23:=arg "height:23" assign
     to41:=arg "height:41" assign
     toggle23:=to23 arg "toggle41:alt+e" assign
     toggle41:=to41 arg "toggle23:alt+e" assign
     toggle41:alt+e

 The example below is a variation of the above macro. It allows you to
 toggle the VGA display between 25-row mode, 43-row mode, and 50-row
 mode by pressing ALT+E. Instead of switching back and forth between
 two modes, it cycles through all three.

 The macro is as follows:

 ;Macro to toggle 25/43/50 line VGA modes
     to23:=arg "height:23" assign
     to41:=arg "height:41" assign
     to48:=arg "height:48" assign
     toggle23:=to23 arg "toggle41:alt+e" assign
     toggle41:=to41 arg "toggle48:alt+e" assign
     toggle48:=to48 arg "toggle23:alt+e" assign
     toggle41:alt+e

 These macros should be placed in your TOOLS.INI file as described
 in Chapters 6 and 7 of the "Microsoft Editor User's Guide."

 Note: the "toggle" functions in these macros not only set the video
 mode, they also change the assignment of function ALT+E. This makes
 these macros similar to self-modifying code. For example, "toggle23"
 not only sets the video mode to 23-rows (with a call to "to23"), it
 also assigns ALT+E to "toggle41" by using the following sequence:

    arg "toggle41:alt+e" assign

 This technique is very useful in learning to write macros.


 65. "Softer" Should Be "Softcr" in M 1.0 User's Guide

 Product Version(s):
 Operating System:   1.00   | 1.00
 Flags: MS-DOS | OS/2
 Last Modified: 18-DEC-1989    ArticleIdent: Q35256
 ENDUSER | docerr

 On Page 61 of the "Microsoft Editor User's Guide," there is a
 documentation error. Softcr is listed as Softer; the correct listing
 is Softcr.


 66. Why Compiling after Editing in M Shows Old Errors

 Product Version(s): 1.00   | 1.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified: 20-OCT-1988    ArticleIdent: Q35258

 When using the M editor (either M.EXE or MEP.EXE) to correct compiler
 or assembler errors, and then compiling/assembling from within M using
 the COMPILE function, it is possible to get the old set of errors
 returned. If the errors occur, check that the autosave switch is set
 correctly. If autosave is off, the corrections are not saved before
 compilation.

 When turned on, the autosave boolean initialization switch causes the
 current file to be saved whenever it is switched away from. The
 default value is on, i.e., the files are automatically saved. The
 setting can be changed from within the editor using Arg textarg Assign
 or else in TOOLS.INI.

 In either case, specify noautosave: to prevent automatic saving of
 files, or autosave: to restore automatic file saving.


 67. How to Read the Contents of the M Editor Clipboard

 Product Version(s): 1.00   | 1.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified: 31-MAR-1989    ArticleIdent: Q35259

 The Clipboard is contained in a pseudofile named <clipboard>. It can
 be loaded the same way any other file is loaded. The contents of the
 Clipboard pseudofile can be examined in several ways.

 The pseudofile <clipboard> can be loaded with the command sequence Arg
 textarg Setfile, which is ALT-A <clipboard> F2 in default keystrokes.
 This process loads the named file. The contents of the clipboard then
 can be seen on the screen, and even can be edited and saved as a
 separate file.

 The file also can be loaded by bringing up the information file with
 the INFORMATION function (SHIFT-F1).

 Finally, if the clipboard is the file most recently switched from, the
 SETFILE function (F2) alone will call it up.

 The information file describes the nature of the Clipboard contents in
 two ways. The Clipboard line appears in the form in the list of
 files, as follows:

 <clipboard>                    *n lines

 Additionally, at the bottom of the information file is a line that
 gives information in one of two ways, as follows:

 n lines in line clipboard

 n lines in box clipboard

 This information indicates whether the Clipboard holds a block of text
 or a stream of text.


 68. How to Write Selected Text to a File in M Editor

 Product Version(s): 1.00   | 1.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified:  1-NOV-1988    ArticleIdent: Q35260

 To write a block or stream of text from a file currently being edited
 to another file (either new or currently existing), do the following:

 1. Select text by using Arg (ALT+A) and the cursor movement keys.

 2. Put the text block or stream into the Clipboard by using the
    functions Copy (CTRL+INSERT, or + on the keypad) or Ldelete
    (CTRL+Y) or Sdelete (DELETE).

 3. Load the desired new file (see the "Working with Multiple Files"
    section of the "Microsoft Editor" manual).

 4. Paste (SHIFT+INSERT) the contents of the Clipboard into the new
    file.

 When writing to a file that does not yet exist, another procedure can
 be used, as follows:

 1. Write the selected text to the Clipboard as described above.

 2. Use Setfile to load the <clipboard> pseudofile the same way that
    other files are loaded.

 3. When the Clipboard contents appear on the screen, save the file to
    the desired new filename with Arg Arg textarg Setfile (ALT+A ALT+A
    filename F2). If a file by that name already exists, it will be
    overwritten.

 4. Return to the originally edited file with Setfile (F2).

 The second method can be put into a macro in one of the following two
 ways:

 1. Create a macro definition for copying to a file of prespecified name
    by using, for example, the following:

 sendtofil:=copy arg "<clipboard>" setfile arg arg "foo.txt" setfile
 setfile

 Assign the macro to a keystroke with an argument of the following
 form, for example:

 sendtofil:alt+s.

 This macro can be placed in TOOLS.INI, or can be the textarg in the
 command to enter a macro, as follows:

 Arg textarg Assign (ALT+A textarg ALT+=).

 2. Create a macro definition for copying to a file of any name by
    using two macros in sequence, for example, as follows:

 send1:=copy arg "<clipboard>" setfile arg arg
 send2:=setfile setfile

 Enter and assign them as described above. To execute this set of
 macros, select the text block or stream, execute the first macro, type
 the desired filename, then execute the second macro.


 69. Macro to Print Part or All of a File from within M

 Product Version(s): 1.00  1.02 | 1.00 1.02
 Operating System:   MS-DOS     | OS/2
 Flags: ENDUSER |
 Last Modified: 21-AUG-1989    ArticleIdent: Q35261

 Microsoft Editor Version 1.00 contains no built-in primitives for
 printing; there is no actual "print" command. However, a set of steps
 can be performed involving the shell function, and a macro can be
 written to execute the steps conveniently. The 1.02 version of the
 Microsoft Editor does contain a print function. For more information
 on Version 1.02's print function, please see Section 4.9, "Printing a
 File," in the "Microsoft Editor User's Guide for MS OS/2 and MS-DOS
 Operating Systems."

 The following is a sample macro for the 1.00 Editor:

    print1:=copy arg "<clipboard>" setfile
    print2:=arg arg "PRINT.TMP" setfile
    print3:=arg "print PRINT.TMP" shell
    print4:=arg "del PRINT.TMP" shell setfile
    print:=print1 print2 print3 print4

 Note: The DOS PRINT command is a resident program. If you shell out of
 M and invoke the PRINT command for the first time, PRINT will be
 loaded above M and you will fragment memory. To prevent this, invoke
 the PRINT command before entering M, so that it will be loaded into
 low memory.

 The following explains the above example:

 1. copy: This copies the currently selected region into the
    clipboard. This way, you can select a region, using a boxarg or
    linearg, and then execute this macro to print it. Because the
    selected region defines what is to be printed, it can be modified
    to suit your needs.

 2. arg "<clipboard>" setfile: This loads the <clipboard> pseudo file
    as the current file.

 3. arg arg "PRINT.TMP" setfile: This saves the contents of the current
    file (which is now <clipboard>) to the file PRINT.TMP.

 4. arg "print PRINT.TMP" shell: This executes a DOS shell that prints
    PRINT.TMP.

 5. arg "del PRINT.TMP" shell setfile: This executes a DOS shell that
    deletes PRINT.TMP, then uses Setfile to return to the original file.


 70. The Difference between M and MEP

 Product Version(s): 1.00   | 1.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | appnote
 Last Modified:  6-JAN-1989    ArticleIdent: Q35522

 The following information is taken from an application note called
 "Microsoft Editor Questions and Answers." The application note also is
 available from Microsoft Product Support Services by calling (206)
 454-2030.

 The Difference between M and MEP?

 M.EXE is the Microsoft Editor that runs under DOS or MS OS/2 real
 mode. MEP.EXE runs under MS OS/2 protected mode only. You may want to
 rename MEP.EXE to M.EXE. Functionally, the two editors are the same,
 except for slight differences in background compilation.


 71. Reassigning Default Keystrokes for Editor Functions

 Product Version(s): 1.00   | 1.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | appnote
 Last Modified:  6-JAN-1989    ArticleIdent: Q35523

 The following information is taken from an application note called
 "Microsoft Editor Questions and Answers." The application note also is
 available from Microsoft Product Support Services by calling (206)
 454-2030.

 Reassigning the Default Keystrokes for Editor Functions

 The function can simply be assigned to an unused keystroke, as
 follows:

 Home:Ctrl+H

 Consult your "Microsoft Editor User's Guide" for valid keystroke
 combinations. If necessary, you can unassign a keystroke by assigning
 it to the function Unassigned, as follows:

 Unassigned:Ctrl+Home


 72. Separating TOOLS.INI Entries for M

 Product Version(s): 1.00   | 1.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | appnote
 Last Modified:  6-JAN-1989    ArticleIdent: Q35524

 The following information is taken from an application note called
 "Microsoft Editor Questions and Answers." The application note also is
 available from Microsoft Product Support Services by calling (206)
 454-2030.

 Making Separate TOOLS.INI Entries for M if You Want to Have Different
 Configurations for M Running Under DOS, OS/2 Real Mode, or OS/2
 Protected Mode, or a Combination of the Three

 Various combinations of tags can be used in TOOLS.INI to set up
 different configurations for different environments. Each environment
 has its own recognized tag. The following is an example:

 Environment:                  Tag:

 MS-DOS                        [M-3.30] (your particular
                                        DOS version)
 OS/2 real mode                [M-10.0R]
 OS/2 protected mode           [M-10.0]

 The following is an examples of combinations:

 MS-DOS and OS/2 real mode     [M-3.30 M-10.0R]
 OS/2 real and protected mode  [M-10.0R M-10.0]

 If you have renamed M.EXE, the "M" used in the tag must be replaced
 with the name you are using for the editor. However, each M-XX.XX
 sub-tag only can appear once in a tag. For example, if you used the
 double tags above, and you were running M in OS/2 real mode, only the
 information from first tag would be loaded.

 By using these tags, only certain sections will be loaded from
 TOOLS.INI to initialize the editor, depending on the environment in
 which the editor is running. The statements in the [M] section are
 always loaded.


 73. Loading a New File into the Editor

 Product Version(s): 1.00   | 1.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | appnote
 Last Modified:  6-JAN-1989    ArticleIdent: Q35525

 The following information is taken from an application note called
 "Microsoft Editor Questions and Answers." The application note is
 available from Microsoft Product Support Services by calling (206)
 454-2030

 Loading a New File into the Editor

 Loading a new file into the editor can be done by using the keystrokes
 corresponding to the following functions:

 Arg textarg Setfile, where textarg is the name of the file you wish to
 load.


 74. Exiting without Saving

 Product Version(s): 1.00   | 1.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | appnote
 Last Modified:  6-JAN-1989    ArticleIdent: Q35526

 The following information is taken from an application note called
 "Microsoft Editor Questions and Answers." The application note is
 available from Microsoft Product Support Services by calling (206)
 454-2030.

 How to Exit without Saving

 Normally, when the keystroke for exit is invoked, the file will be
 saved before exiting. However, typing the keystroke for "Meta" before
 the exit keystroke allows you to exit without saving your file.


 75. Merging Two Files Together

 Product Version(s): 1.00   | 1.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | appnote
 Last Modified:  6-JAN-1989    ArticleIdent: Q35527

 The following information is taken from an application note called
 "Microsoft Editor Questions and Answers." The application note also is
 available from Microsoft Product Support Services by calling (206)
 454-2030.

 How to Merge Two Files Together

 A separate file can be merged into the current file by using the
 keystrokes corresponding to the following functions:

    Arg Arg textarg Paste, where textarg is the name of file to be merged.


 76. Placing Control Characters in Text of File

 Product Version(s): 1.00   | 1.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | appnote
 Last Modified:  6-JAN-1989    ArticleIdent: Q35528

 The following information is taken from an application note called
 "Microsoft Editor Questions and Answers." The application note also is
 available from Microsoft Product Support Services by calling (206)
 454-2030.

 Placing Control Characters in the Text of My File

 The editor function "Quote" can be used to place special characters in
 your text. Use the keystroke assigned to "Quote", then enter the
 combination of keys necessary to produce the character. For example, a
 Form Feed would be a combination of the CTRL key and the L key.


 77. Compiling the Program Currently Loaded in Editor

 Product Version(s): 1.00   | 1.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | appnote
 Last Modified:  6-JAN-1989    ArticleIdent: Q35529

 The following information is taken from an application note called
 "Microsoft Editor Questions and Answers." The application note is
 available from Microsoft Product Support Services by calling (206)
 454-2030.

 How to Compile the Program Currently Loaded in the Editor

 The current file can be compiled by using the keystrokes corresponding
 to the following functions:

    Arg Arg textarg Compile, where textarg is the compiler command
    line typed as you normally would outside of the editor; however,
    the filename does not have to be the current file.

 The text switch "extmake" can be entered in TOOLS.INI to associate a
 frequently used command line with a particular file extension. The
 following is an example:

    extmake:c cl /Zi /Od %s

 The %s will be replaced with the current filename.


 78. Differences between the vscroll and hike Numeric Switches

 Product Version(s): 1.00   | 1.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | appnote
 Last Modified:  6-JAN-1989    ArticleIdent: Q35530

 The following information is taken from an application note called
 "Microsoft Editor Questions and Answers." The application note also is
 available from Microsoft Product Support Services by calling (206)
 454-2030.

 The Differences between the vscroll and hike Numeric Switches

 The vscroll switch determines how many lines are vertically scrolled
 when the cursor is moved to a location not visible in (outside of) the
 current window but within vscroll lines of the edge of the current
 window.

 The hike switch determines the cursor position when an editing
 function moves the cursor more than vscroll lines beyond the edge of
 the current window. In this case, the cursor would appear hike lines
 from the top of the window.

 Note: Currently, these switches are broken. Even when vscroll is
 correctly set to 1, hike will overide it if hike has a greater value
 than vscroll. Until this problem is corrected, both switches must be
 set to 1 to scroll one line at a time.


 79. Making the Editor Default to Insert Mode

 Product Version(s): 1.00   | 1.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | appnote
 Last Modified:  6-JAN-1989    ArticleIdent: Q35531

 The following information is taken from an application note called
 "Microsoft Editor Questions and Answers." The application also is
 available from Microsoft Product Support Services by calling (206)
 454-2030.

 How to Make the Editor Default to Insert Mode

 The boolean switch "Enterinsmode" can be set in the TOOLS.INI file to
 allow the editor to start up in insert mode rather than overtype mode.
 This switch is off by default, but can be set by adding the following
 entry to TOOLS.INI:

    enterinsmode:


 80. Saving Files Under a Different Name

 Product Version(s): 1.00   | 1.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | appnote
 Last Modified:  6-JAN-1989    ArticleIdent: Q35532

 The following information is taken from an application note called
 "Microsoft Editor Questions and Answers." The application note also is
 available from Microsoft Product Support Services by calling (206)
 454-2030.

 How to Save Your File Under a Different Name

 Saving a file under a different name can be done by including a
 textarg when saving a file without exiting, as follows:

    Arg Arg textarg Setfile, where textarg is the filename you wish to
    save the file under.


 81. "Unable to Open Swapping File c:\temp\m-0029.vm"

 Product Version(s): 1.00   | 1.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | appnote
 Last Modified:  6-JAN-1989    ArticleIdent: Q35533

 The following information is taken from an application note called
 "Microsoft Editor Questions and Answers." The application note also is
 available from Microsoft Product Support Services by calling (206)
 454-2030.

 "Unable to Open Swapping File c:\temp\m-0029.vm No Such File or
 Directory" Error

 The editor assumes that environment variables are set so that
 important editor information can be loaded from and saved to your
 disk. The following is an example:

    SET INIT=c:\init
    SET TMP=c:\temp

 In this example, c:\temp would be the directory that would hold
 temporary or swapping files, usually named M-0029.VM. This file is
 used to allow the editor to switch to previous files. C:\INIT would
 hold TOOLS.INI and M.TMP. The swapping file also would be stored here
 if the TMP variable was not set. If neither of these variables is
 set, the swapping file would be stored in the root directory and M.TMP
 would be stored in the current directory.

 However, if the TMP variable is set to a directory that does not
 exist, or if extra characters were included after the "p" in "c:\temp"
 such as a space or a semicolon, the swapping file will not be created
 and the error above will be generated.


 82. Why the Editor Cannot Find or Load TOOLS.INI

 Product Version(s): 1.00   | 1.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | appnote
 Last Modified:  6-JAN-1989    ArticleIdent: Q35534

 The following information is taken from an application note called
 "Microsoft Editor Questions and Answers." The application note also is
 available from Microsoft Product Support Services by calling (206)
 454-2030.

 Why the Editor Can't Find or Load the TOOLS.INI File

 There are several reasons this problem may occur. First of all, you
 may have never created a TOOLS.INI file. If TOOLS.INI is not in the
 working directory, the INIT environment variable must specify the
 directory that contains this file. Within the TOOLS.INI file, there
 must be a tag that has the same name as the editor (M.EXE), as
 follows:

    [m]

 If you have renamed the editor you also must rename the tag. Entries
 concerning the editor then would follow after this tag. Under DOS
 Versions 2.x, the Microsoft Editor looks for a [c] tag rather an [m]
 tag or whatever you have renamed M.EXE to.


 83. Keeping the Editor from Saving Backup Files

 Product Version(s): 1.00   | 1.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | appnote
 Last Modified:  6-JAN-1989    ArticleIdent: Q35535

 The following information is taken from an application note called
 "Microsoft Editor Questions and Answers." The application note also is
 available from Microsoft Product Support Services by calling (206)
 454-2030.

 How to Keep the Editor from Saving Backup Files

 The text switch "Backup" determines what happens to old copies of
 files that are modified. If you do not wish to keep any backup files,
 a value of "none" can be given, as follows:

    Backup:none

 Backup files can be saved in two ways. A value of "bak" will save the
 previous version of the file with a .BAK extension. A value of "undel"
 will save a history of old copies of your file in a hidden directory
 disk space.

 Older copies can be restored by using UNDEL.EXE. Typing "undel" will
 list all the backup copies; "undel <filename>" will either restore the
 file, or if there is more than one backup, it will allow you to choose
 which version you would like to restore. Because these files take up
 actual disk space, they should be periodically removed from the disk
 by using EXP.EXE. Typing "exp" will delete these files permanently.


 84. How to Write and Use C Extensions

 Product Version(s): 1.00   | 1.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | appnote
 Last Modified:  6-JAN-1989    ArticleIdent: Q35536

 The following information is taken from an application note called
 "Microsoft Editor Questions and Answers." The application note also is
 available from Microsoft Product Support Services by calling (206)
 454-2030.

 C Extensions and How to Write and Use Them

 C extensions allow you to further customize the editor by creating new
 editor functions and switches through programs that you write in the C
 programming language. They are much more powerful than macros because
 macros depend on the existence of editor functions.

 C extensions are compiled with a special memory-model that does not
 use a main() function, but rather uses special names and structures
 that the editor alone recognizes. They are linked with an object
 module that makes low-level functions used within the editor itself
 available to be called by your C extension. The file produced from
 linking is separate from the main program but is loaded into memory
 with the editor. The editor then will call your module whenever you
 invoke one of your C extension functions.


 85. Developing Macros

 Product Version(s): 1.00   | 1.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | appnote
 Last Modified:  4-MAY-1989    ArticleIdent: Q35537

 The following information is taken from an application note called
 "Microsoft Editor Questions and Answers." The application note also is
 available from Microsoft Product Support Services by calling (206)
 454-2030.

 Develop my Own Macros

 Developing a macro is similar to programming in a high-level language.
 Each macro represents a command. Instead of a collection of library
 routines, you have a collection of editor functions. You begin with an
 idea of a process that you would like to be performed by simply
 pressing one keystroke.

 Suppose you would like to be able to move the cursor to the lower-left
 corner of the editing window. You know you can do this "manually" with
 the arrow keys that are assigned to the "Left" and "Down" editor
 functions. However, it can be simplified more. "Meta Down" moves the
 cursor to the bottom of the window; "Meta Begline" moves the cursor to
 the first column of the line. Together, these functions will do the
 job.

 This macro must now be given a unique name, for example, "Bottom". The
 TOOLS.INI statement would look as follows:

    Bottom:=Meta Begline Meta Down

 A macro also can be a combination of other macros. The following is an
 example:

    Waydown:=Meta Down
    Wayleft:=Meta Begline
    Bottom:=Waydown Wayleft

 Suppose that the "Meta Begline" command did not exist. You would need
 to find some way to know that the cursor is in the first column.
 Almost all of the editor functions have boolean (TRUE/FALSE) Return
 Values that can be useful in developing macros.

 For the "Bottom" macro, you know that "Begline" will at least move the
 cursor to the first nonblank character on the line. Any further cursor
 movement would have to be done using "Left". "Left" returns TRUE when
 the cursor moves and FALSE when the cursor does not move.

 You would want to move left until the cursor does not move anymore,
 i.e., move left until "Left" returns FALSE. The editor allows you to
 do this with Macro Conditionals. The following is an example:

    Bottom:=Begline :>LT Left +>LT Meta Down

    :>LT   defines a label LT
    +>LT   if Left returns TRUE, go to label LT
           if Left returns FALSE, continue

 Macro Conditionals and a table of Return Values can be found in the
 "Microsoft Editor User's Guide."

 The final step is to assign the macro to a keystroke, as follows:

    Bottom:CTRL+END


 86. Saving without Exiting

 Product Version(s): 1.00   | 1.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | appnote
 Last Modified:  6-JAN-1989    ArticleIdent: Q35538

 The following information is taken from an application note called
 "Microsoft Editor Questions and Answers." The application note also is
 available from Microsoft Product Support Services by calling (206)
 454-2030.

 Saving without Exiting

 You can save a file without exiting by using the keystrokes
 corresponding to the following functions:

    Arg Arg Setfile.

 A macro can be written to perform these functions in one keystroke
 (Alt+S), as follows:

    Save:=Arg Arg Setfile
    Save:Alt+S


 87. None Assignment Must Be Lowercase

 Product Version(s): 1.00   | 1.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified:  1-NOV-1988    ArticleIdent: Q35648

 When using the backup:none option in the TOOLS.INI file, the none
 cannot begin with a capitol N.

 The "None is an illegal setting" error will be generated if you have
 Backup:None (capitol N) in the TOOLS.INI file.

 The correct form is backup:none


 88. Width Function Not implemented

 Product Version(s): 1.00   | 1.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified: 20-OCT-1988    ArticleIdent: Q35649

 Some graphics cards allow the monitor to go into modes greater than 80
 columns. The Microsoft Editor has a function called Width to allow
 more than 80 columns, however, this function has not yet been
 implemented.

 This feature is under review and will be considered for inclusion in
 a future release.


 89. M on an AMDEK System 88 XT Clone

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 30-SEP-1988    ArticleIdent: Q35817

 Problem:

 When running M on an AMDEK System 88, which is an XT clone, the M
 editor hangs the machine requiring a warm boot. The machine was using
 an EPC Keyboard that is an AT style keyboard.

 Response:

 This is a known incompatibility with this hardware configuration and M
 Version 1.00. AMDEK is aware of this problem and has a patch that they
 can send you. To obtain a patch, call AMDEK at (408) 435-2832. The
 patch contains the following three files:

 READ.ME
 CLREPC.EXE
 SETEPC.EXE.

 The problem is that M was checking the keyboard, which in this case
 was an AT style keyboard, and assuming it was running on an AT clone.
 This situation caused the hang.

 By running SETEPC.EXE, a switch is set so M sees the keyboard as a XT
 keyboard and everything functions properly. CLREPC.EXE clears this
 switch.


 90. Placing the NULL Character in a File with M/MEP

 Product Version(s): 1.00   | 1.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified: 20-OCT-1988    ArticleIdent: Q35819

 Problem:

 I would like to place the null character in a file using M or MEP. I
 have tried using the Quote function and successfully put other
 non-printable characters in the file, such as the bell character.
 However, attempts to place a null in the file with the Quote function
 were ignored. Is this possible?

 Response:

 No. Placing null characters in a file with M/MEP is not possible. The
 editor uses null-terminated strings internally, as well as NULL return
 values from some character functions. Because the editor uses the null
 character, you are not allowed to use null.


 91. Case Sensitivity of Switches

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 31-OCT-1988    ArticleIdent: Q36415

 The BACKUP text switch is case sensitive with the arguments given it.
 The arguments "undel", "bak", and "none" need to be lowercase, otherwise
 an error will be reported.



 92. Intitialize function is Shift+F8

 Product Version(s): 1.00   | 1.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | docerr
 Last Modified:  2-NOV-1988    ArticleIdent: Q36567

 There is a documentation error on Page 64 of the "Microsoft Editor for
 MS OS/2 and MS-DOS Operating Systems User's Guide". The line

 3. Invoke the Initialize function (press F10).

 should read as follows :

 3. Invoke the Initialize function (press SHIFT+F8)

 The F10 should be replaced with SHIFT+F8. SHIFT+8 is the default.


 93. Percent (%) Character in Filenames

 Product Version(s): 1.00   | 1.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | buglist1.00
 Last Modified: 20-OCT-1988    ArticleIdent: Q36570

 The Microsoft Editor cannot handle a percent sign as the first
 character in the filename (%test.dat). While this is a valid DOS
 filename, it will cause garbage to be printed on the status line and
 may generate a run-time error.

 Microsoft has confirmed this to be a problem in Version 1.00. We are
 researching this problem and will post new information as it becomes
 available.

 If you fill a line with 250 characters (the maximum), then press HOME
 to go to the beginning of the line and delete the line by pressing
 CTRL-Y, the editor will crash with the following error:

         run-time error R6003
         -integer divide by 0

 Both of the above problems only occur when a percent sign is used as
 the first character in the filename. To work around this problem, do
 not use the percent sign as the first character.



 94. How Tabs Are Treated in the Microsoft Editor

 Product Version(s): 1.00   | 1.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified: 14-OCT-1988    ArticleIdent: Q36580

 Problem:

 Some text editors preserve tab characters automatically. These editors
 maintain tabs (ASCII 9 characters) as they are stored in a file, and
 distinguish between tab characters and spaces.

 The Microsoft Editor translates tab characters into spaces. This
 behavior only affects lines that you modify. If you load and save a
 file without changing any lines of text, the lines are written back to
 disk with all tab characters and spaces intact. Only the modified
 lines are affected by this conversion.

 It is not possible to disable this translation of tab characters into
 spaces in a modified line.

 In the Microsoft Editor, "tab"  is both a function name and the name
 of a key. The TAB key is assigned to the tab function by default. As a
 function, tab is nothing more than a move-to-next-column movement
 function. The placement of columns in determined by the TABSTOPS
 switch.

 When ever you edit a line, tab characters are translated to space
 characters using the FILETAB switch. So modified lines in the file are
 stored in the editor with spaces only. The FILETAB switch determines
 how the editor translates tab characters to spaces when reading in a
 line of text. If ENTAB is set to 1 or 2, then FILETAB also determines
 how the editor translates spaces to tabs when you save the file to
 disk. (Again, only modified lines are affected.)

 If you need to view the tabs as they are situated in your file you can
 use the TABDISP switch to show you which spaces will be compressed
 into a tab character at the next write to the disk file.


 95. 43- and 50-Line Modes

 Product Version(s): 1.00   | 1.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified: 20-OCT-1988    ArticleIdent: Q36613

 The M editor can make use of the 43-line EGA text mode and 50-line VGA
 text mode. The "height" numeric switch in the TOOLS.INI file specifies
 the number of lines used in the editing window; however, this number
 does NOT include the dialog and status display lines. Thus, to use 43
 lines of text you must set height=41; to use 50 lines you must set
 height=48.


 96. Microsoft System Journal M macros Fail

 Product Version(s): 1.00 1.01 | 1.00 1.01
 Operating System:   MS-DOS    | OS/2
 Flags: ENDUSER |
 Last Modified: 20-OCT-1988    ArticleIdent: Q36798

 In the September 1988 issue of the "MS System Journal," the article
 entitled "Customizing the Features of the M Editor Using Macros and C
 Extensions" contains erroneous examples.

 Both of the macros below fail in Version 1.00. Only the Bigprint macro
 fails in Version 1.01.

 The following is an example:

 Macro 1)

 ;print selected text macro
 print1:= copy arg "<clipboard>" setfile
 print2:= arg arg "TEMP.DAT" setfile setfile
 print3:= arg "PRINT TEMP.DAT" shell
 print4:= arg "DEL TEMP.DAT" shell
 printa:=print1 print2 print3 print4
 Printa:alt+P

 The above macro is supposed to print selected text. In M Version 1.00
 it works correctly the first time it is called from inside a file.
 However, it fails on subsequent calls to the macro prior to exiting
 the file. It does work correctly in the unreleased Version 1.01
 referenced in the article.

 The following macro is supposed to print the entire file. Instead, it
 prints only the line on which the cursor sits when the macro is
 called. As mentioned above, this fails in both Versions 1.00 and the
 unreleased Version 1.01 referred to in the article on Pages 59-72.

 The following is an example:

 Macro 2)

 ;bigprint macro to print entire file
 select1:= arg ppage
 select2:= arg arg "endoffile" mark
 select3:= arg mpage
 select4:= arg "endoffile"
 selectall:= select1 select2 select3 select4
 bigprint:=meta +>nometa cancel selectall meta :>nometa meta printa

 bigprint:Alt+z
 ;end of bigfoot macro.


 97. meta Anomalous Behavior

 Product Version(s): 1.00   | 1.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | buglist1.00
 Last Modified: 31-OCT-1988    ArticleIdent: Q37072

 The following macros written for the M editor exhibit anomalous
 behavior for the function modifier meta. It appears that meta cannot
 modify itself, as demonstrated by the following macros.

 Microsoft has confirmed this to be a problem in Version 1.00. We are
 researching this problem and will post new information as it becomes
 available.

 Consider the following macros:

    MetaTest:= meta meta +> "meta off"=>0 :>1 "meta on":>0
    MetaTest:alt+0
    ; the above macro is supposed to check to see if the function
    ; modifier meta, invoked by the F9 key, is on or off. Compare
    ; the results of this macro with the macro immediately following.
    MetaTest1:= meta +> "meta off"=>0 :>1 "meta on":>0
    MetaTest1:alt+1
    ; the MetaTest1 macro fails to differ from the MetaTest macro in
    ; a significant manner. in contrast, consider the following
    ; macro, employing the insetmode function modifier.
    InsertTest:=insertmode insertmode +> "ins off"=>0 :>1 "ins on":>0
    InsertTest:alt+2.


 98. MASM m.exe Is Different than FORTRAN m.exe when Using DOS Comp

 Product Version(s): 1.00   | 1.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | h_fortran
 Last Modified:  6-JAN-1989    ArticleIdent: Q38015

 Question:

 When I do a Comp command at the DOS prompt, why do the FORTRAN Version
 4.10 and MASM Version 5.10 packages contain m.exe files that differ at
 offset 15F9F, where the MASM m gives 37 and the FORTRAN m gives 38?
 Which one should I use for mixed-language programming?

 Response:

 This behavior is an error that was discovered after MASM Version 5.10
 was released, but before FORTRAN Version 4.10 was shipped. You can see
 this by invoking the editor and entering SHIFT+F1, which gives you
 file information. The date given in the MASM file is Jan. 29, 1987
 (hex37) when it should be Jan. 29, 1988 (hex 38). Other than this
 character in the date, they are identical, so you can use either one
 for mixed-language programming.


 99. Selecting Large Text Blocks with Microsoft Editor

 Product Version(s): 1.00   | 1.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified:  4-MAY-1989    ArticleIdent: Q38309

 Question:

 When I want to select a large block of code for the clipboard, I press
 ALT+A, then the DOWN ARROW key until I reach the last line I want to
 select. This process is very slow if the block I am selecting is
 several pages long (almost a whole file). Is there a way to move
 faster to select a block than by using the CURSOR key (such as the
 equivalent of ^K-B and ^K-K in Wordstar)?

 Response:

 CTRL+PGDN (Ppara) serves this purpose, as documented on Pages 91 and
 104 of the "Microsoft Editor for MS OS/2 and MS-DOS Operating Systems:
 User's Guide." This key sequence will move you to a new paragraph each
 time you press the keys. If the movement sequence you want to use
 contains an Arg, it is either used by the command or canceled.

 A faster method is to define a couple of macros to help out. First, we
 need a macro that will mark the beginning spot in the text, as
 follows:

    txtmark:=arg arg "first" mark
    txtmark:alt+t

 The second macro automates using the mark as an argument, as follows:

   callmark:=arg "first"
   callmark:alt+u

 You can put these lines in your TOOLS.INI file.

 To use this pair, move to the first spot, press ALT+T, then move up or
 down using any movement keys to the second spot. Finally, press ALT+U
 and press a key that allows a markarg as an argument. (The Copy and
 Ldelete functions are among these.) Note: no highlighting occurs, so
 you'll have to be careful.

 Note: if you want the argument to be entire lines rather than a box,
 the cursor MUST be in the same column when you press ALT+U as it was
 when you pressed ALT+T. If you put it in a different column, you will
 be selecting a box argument rather than a line argument.


 100. Moving to the Beginning of the Line with Microsoft Editor

 Product Version(s): 1.00   | 1.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified:  6-JAN-1989    ArticleIdent: Q38310

 Question:

 Is there a way to go to column 1 of the screen with a key sequence
 instead of pressing the LEFT ARROW key until the cursor stops at
 column 1? I find myself wasting a lot of time doing this repetitive
 chore. The HOME key only takes me to the beginning of the text on the
 line, not the beginning of the line, which is where I want to be if I
 want to delete a line, for example. I currently use ^K-S with the
 Wordstar extension.

 Response:

 Meta Begline (F9 HOME in the standard configuration) will do it. If
 you'd like it on one key, you can assign the functions to a key using
 the macro facility.


 101. Inserting a Line from Clipboard into File with Editor

 Product Version(s): 1.00   | 1.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified: 15-MAY-1989    ArticleIdent: Q38311

 Question:

 I am confused by the way a line is inserted from the clipboard into a
 file. It seems to depend on whether Insert is On or Off. Also, it
 sometimes pushes the other lines down and sometimes it pushes the
 existing line to the right. I see no consistency to all this. Can you
 explain the concepts?

 Response:

 The Insert mode has no bearing on line insertion. However, how you
 delete the line has a lot to do with it. In general, don't use the
 DEL key for multiple-character deletions. It is usually assigned to
 the sdelete function, which always deletes a stream of text, as
 documented on Page 107 of the "Microsoft Editor for MS OS/2 and MS-DOS
 Operating Systems: User's Guide."

 A stream is all of the text between the place where the cursor was
 when you typed Arg and where it is when you press sdelete, regardless
 of the beginning and ending cursor columns or how many lines are
 contained in the region. Whenever you mark an area and press sdelete
 (the DEL key), you will delete the STREAM you have marked, even
 though the region highlighted may look different.

 It's usually best to use CTRL+Y (Ldelete) for deletions which begin
 and end on different lines. Note that the COPY key (CTRL+INS) does not
 accept stream arguments, therefore, it always copies the highlighted
 area.


 102. Use a Colon when Assigning a Macro to a Keystroke

 Product Version(s): 1.00   | 1.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | docerr
 Last Modified: 12-JAN-1989    ArticleIdent: Q39574

 There is a documentation error on Page 50 of the "Microsoft Editor
 User's Guide." Section 6.3.2 incorrectly shows a semicolon when
 assigning a macro to a keystroke as follows:

    Header;ALT+H

 The correct example should contain a colon as follows:

    Header:ALT+H


 103. Quote Function and Typing in Graphic Characters in M

 Product Version(s): 1.00   | 1.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified: 16-MAY-1989    ArticleIdent: Q39806

 Question:

 I want to input some graphics characters in the M editor. However,
 when I try to input the ASCII character 31 using the ALT key and the
 numeric keypad, the M editor beeps and displays the following message:

    "ctrl+_ is not assigned to any editor function"

 For the ASCII character 30, the M editor displays the following
 message:

    "ctrl+^ is not assigned to any editor function."

 How can I input those characters?

 Response:

 Use the editing Quote function in the M editor. The Quote function is
 associated with CTRL+P by default. After the Quote function is
 invoked, the following keystroke is taken literally. This function is
 mentioned in the "Microsoft Editor for MS OS/2 and MS-DOS Operating
 Systems User's Guide" on Page 105.

 The first 32 characters in the ASCII character set have two
 conflicting uses. As standard ASCII characters, they are used for
 communications control and printer control. They are also used by IBM
 to represent some useful graphics characters.

 Using the Quote function in the M editor can prevent these ASCII
 characters from being interrupted as control characters.


 104. M Hangs if the textarg Given to ArgCompile Is Incomplete

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 12-JAN-1989    ArticleIdent: Q40235

 If you want to compile a program inside the M editor using the
 following command, textarg should contain the full compile line as
 typed at the DOS prompt:

    Arg Arg textarg ArgCompile

 The following is an example:

    cl /Zi /Od demo.for

 If textarg contains just the name of the program (demo), the hard disk
 light will come on and the message "compilation complete" will appear
 on the bottom of the screen even though demo.for was not compiled.

 If textarg contains the full program name (demo.for), your computer
 hangs if you press SHIFT+F3. Sometimes, there will be lost clusters
 and allocation errors as reported by chkdsk.

 This problem was not encountered under OS/2.



 105. Redirecting Errors to an Error File in M

 Product Version(s): 1.00   | 1.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified:  1-MAY-1989    ArticleIdent: Q40177

 Under DOS, M Version 1.00 will store the error messages in the M.MSG
 file. This file is located in the directory the TMP environment
 variable points to. If TMP is not set, this file is located in
 the current working directory. Under OS/2, MEP uses named pipes, so
 there is no file to look at.


 106. FileWrite() Function Fails to Write Back Out to the File

 Product Version(s): 1.00   | 1.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified: 15-MAY-1989    ArticleIdent: Q40356

 Problem:

 I have a problem using the FileWrite Function programming with the M
 and MEP Editor Version 1.00. I want to read a file (EXAMPLE.DOC) and
 write exactly the same in a new file (FOO.DOC).

 Response:

 To test the example below, you only have to create a file named
 EXAMPLE.DOC. See the compiler switches at the end of this article. The
 second file FOO.DOC is created, but it is never written to it always
 has zero length.

 This is a problem with MEP Version 1.00's FileWrite() function. This
 is one of the problems that kept the filter extension described in the
 "Microsoft Systems Journal" September 1988 from working in Version
 1.00.

 Microsoft has confirmed this to be a problem in Version 1.00. We are
 researching this problem and will post new information as it becomes
 available.

 The following is a short example where the problem (Function FileWrite
 does not write) occurs:

 #include "ext.h"
 #define TRUE    -1
 #define FALSE   0
 #define NULL    ((char *) 0)

 flagType pascal EXTERNAL Write(
 unsigned int argData,
 ARG far * pArg,
 flagType fMeta)
 {
     flagType flg;
     PFILE pFile;
     char  *p = "EXAMPLE.DOC";
     char  *w = "FOO.DOC";

     if((pFile = FileNameToHandle(p,NULL)) == 0)
     {
         pFile = AddFile(p);
         FileRead(p, pFile);
     }
     flg = FileWrite(w, pFile);
     return (flg);
 }

 struct swiDesc  swiTable[] ={
     { NULL, NULL, 0 }
 };

 struct cmdDesc  cmdTable[] ={
     {"Write", Write, 0, NOARG },
     {NULL,  NULL, 0, 0}
 };

 void EXTERNAL WhenLoaded (void)
 {
     SetKey("Write", "alt+w");
     DoMessage("Write function now loaded.");
 }

 /*

 *** Compiler switches I used ***

 cl /c /Gs /Asfu %1.c
 cl /Lp /AC /Fe%1.dll exthdrp.obj %1.obj skel.def

   */


 107. Optimizing C or QuickC 2.00 Required for Writing C Extensions

 Product Version(s): 1.00   | 1.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | S_C S_QuickC
 Last Modified: 17-MAY-1989    ArticleIdent: Q39997

 Question:

 I would like to customize the Microsoft Editor by writing C
 extensions. Can I use QuickC Version 1.00, QuickC Version 1.01, or
 QuickC Version 2.00?

 Response:

 No. You must use the Microsoft C Version 4.00 Optimizing Compiler or a
 later version to write C extensions to the Microsoft Editor. QuickC
 Versions 1.00 and 1.01 cannot be used because they do not support the
 required switch /Asfu.

 However, Version 2.00 does support the /Asfu switch when using QCL.
 Therefore, you can use Version 2.00 and QCL to create C extensions.

 For more information, see Pages 68 and 83 of the "Microsoft Editor for
 MS OS/2 and MS-DOS Operating Systems: User's Guide."


 108. Search and Replace Macro for M Editor

 Product Version(s): 1.00   | 1.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified: 12-JAN-1989    ArticleIdent: Q39998

 Question:

 Can you write a macro to perform a search and replace on a particular
 string? When I try to do so, the replace function prompts me for a
 string argument. I want the replace function to read the string from
 the macro.

 Response:

 The following is an example of a replace macro that accepts its
 argument from inside the macro:

    myreplace:=replace "oldtext" newline "newtext" newline

 When the myreplace macro is invoked, all the occurrences of "oldtext"
 string, from the cursor position to the end of the file, are replaced
 with the "newtext" string. The use of the newline function allows the
 macro to respond to the replace-function prompt for a string argument.

 To define the myreplace macro and assign it to the F12 key, enter the
 following keystrokes from inside the M editor:

    ALT+A
    MyReplace:=replace "oldtext" newline "newtext" newline
    ALT+=

    ALT+A
    MyReplace:F12

 To execute the myreplace macro, press the F12 key.


 109. M.TMP Reset When Window Closed

 Product Version(s): 1.00   | 1.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | mep buglist1.00
 Last Modified: 15-MAY-1989    ArticleIdent: Q40681

 Question:

 When I invoke the M editor, open a second window (arg F6 or arg arg
 F6), and close the first window (meta F6), my M.TMP file is reset. The
 only file in my M.TMP file is the one that I edited to perform this
 operation. Is there a way to prevent this from happening?

 Response:

 This phenomena occurs whenever you close a window that has had a file
 opened in it. Hence, if you open a file in the second window, then
 close the second window, M.TMP is reset. To avoid this behavior, don't
 close a window in which a file has been opened.

 Microsoft has confirmed this to be a problem in Version 1.00. We are
 researching this problem and will post new information as it becomes
 available.



 110. QHMEP.DLL Remaps Two Keys in MEP Version 1.00

 Product Version(s): 1.00
 Operating System:   OS/2
 Flags: ENDUSER | buglist1.00
 Last Modified: 16-MAY-1989    ArticleIdent: Q41324

 Problem:

 I have remapped the keys CTRL+S and CTRL+P in MEP Version 1.00 to the
 psearch and up functions. After loading the extension QHMEP.DLL, which
 comes with the Version 1.06 OS/2 SDK, the two keys CTRL+S and CTRL+P
 are not mapped to psearch and up anymore. Furthermore, these keys
 cannot be reassigned back to psearch and up. I seem to be locked out
 of using these keys.

 Response:

 This problem occurs because the editor is taking over these keys,
 preventing them from being reassigned.

 Microsoft has confirmed this to be a problem in MEP Version 1.00. We are
 researching this problem and will post new information as it becomes
 available.



 111. Useful Macros for the Microsoft Editor

 Product Version(s): 1.00    |  1.00
 Operating System:   MS-DOS  | OS/2
 Flags: ENDUSER |
 Last Modified: 16-MAY-1989    ArticleIdent: Q40755

 Below are macros for the Microsoft Editor that allow you to save a
 marked portion of a file and insert it into another file. Also, there
 are macros that speed up marking large areas of text.

 To save a marked area of a file, mark the area and invoke this macro
 by typing ALT+V. Note that although the macro is broken onto two lines
 here, you should put it on one line in your TOOLS.INI file.

 savemark:=copy arg "command /c del c:\\t" shell arg "\\t" setfile
           refresh paste setfile
 savemark:alt+v

 A one-key way to include the file in another file is to use the macro
 by typing ALT+I:

 insertmark:=arg arg "\\t" paste
 insertmark:alt+i

 To mark the top and bottom of the text area, use these macros. Type
 ALT+T to place the marker, then ALT+U to use it. Type CTRL+INS or
 CTRL+Y to copy or delete the text. Note that if your cursor is not in
 the same column when you type ALT+U as when you typed ALT+T, the area
 marked will be a box rather than a set of lines. Note also that the
 marked area will NOT show up on the screen.

 tempmark:=arg arg "temp" mark
 usemark:=arg "temp"
 tempmark:alt+t
 usemark:alt+u



 112. Using Brief Emulation and Tags in TOOLS.INI

 Product Version(s): 1.00   | 1.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | buglist1.00
 Last Modified: 17-MAY-1989    ArticleIdent: Q41475

 If you invoke a tagged section from your TOOLS.INI when using the
 Microsoft editor with brief keystroke emulation, some of the key
 assignments will revert back to the default.

 Microsoft has confirmed this to be a problem in Version 1.00. We are
 researching this problem and will post new information as it becomes
 available.

 As demonstrated in the following example, some of the keystrokes are
 reassigned to the default keystrokes if you rename the BRIEF.INI file
 to be TOOLS.INI and then add a new tag section:

 [m-mono]
     height:23
     fgcolor:07
     errcolor:0F
     stacolor:70
     infcolor:70

 Start editing a file, then bring in this new tag field by typing the
 following:

    arg "mono" shift+f10

 The following demonstrates this behavior and all compile lines revert
 to default:

    window             will change from F1 to unassigned
    help               will change from ALT+H to F1
    argcompile         will change from ALT+F10 to F5
    save               will change from ALT+W to undefined
    linemark           will change from ALT+I to undefined
    linetotop          will change from CTRL+T to undefined
    leftsideofwindow   will change from SHIFT+HOME to undefined
    rightsideofwindow  will change from SHIFT+END to undefined
    createhorizwindow  will change from F3 to undefined
    createvertwin      will change from F4 to undefined
    deletewindow       will change from F5 to undefined



 113. Minimum Requirements for Writing a M Extension

 Product Version(s): 1.00   | 1.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified: 16-MAY-1989    ArticleIdent: Q42241

 Question:

 What files and software do I need to be able to write an extension for
 the Microsoft Editor?

 Response:

 To create C extensions, you need to have the following files and
 software present in your current directory (or directories listed in
 the PATH or INCLUDE environment variables, as appropriate):

 1. The Microsoft C Optimizing Compiler Version 4.00 or later;
    or Microsoft QuickC Version 2.00

 2. The Microsoft Overlay Linker Version 3.60 or later; or the
    Microsoft Segmented-Executable Linker Version 5.01

 3. EXTHDR.OBJ (supplied with the editor) or EXTHDRP.OBJ (a file
    supplied with the editor for creating protected-mode extensions)

 4. EXT.H header file provided with the editor

 5. SKEL.DEF, the standard definitions file supplied with the editor;
    to be used with all extension

 You need a minimum 150K of available memory for the editor to load a C
 extension at run time in addition to the size of the extension itself.


 114. 43- and 50-Line Modes with the IBM 8514 Monitor

 Product Version(s): 1.00 1.02
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist1.00 fixlist1.02
 Last Modified: 28-JUL-1989    ArticleIdent: Q42365

 The Microsoft Editor does not go into 43- or 50-line line mode on the
 IBM 8514 monitor.

 Version 1.00 of the Microsoft Editor does not support higher line
 modes with the IBM 8514 monitor. Regardless of the switch setting you
 give in the TOOLS.INI file, it always comes up in 25-line mode.

 For example, setting the height:41 or height:48 switch in the
 TOOLS.INI file results in the Microsoft Editor coming up in 25-line
 mode.

 Microsoft has confirmed this to be a problem in Version 1.00 of the
 Microsoft Editor. This problem was corrected in the Microsoft Editor
 Version 1.02.


 115. Savecur and Restcur Save Relative Position in File, on Screen

 Product Version(s): 1.00   | 1.00
 Operating System:   MS-DOS | OS2
 Flags: ENDUSER |
 Last Modified: 17-MAY-1989    ArticleIdent: Q42758

 The Microsoft Editor functions Savecur and Restcur save the current
 cursor position relative to the file and the screen. Therefore, the
 screen will be restored exactly as it appeared when the Savecur
 function was invoked.

 The following macros were intended to scroll the screen up and down
 while leaving the cursor position relative to the terminal screen to
 be stationary:

 ReposDown:=Savecur Meta Up Up Restcur
 ReposDown:Ctrl+Down

 ReposUp:=Savecur Meta Down Down Restcur
 ReposUp:Ctrl+Up

 Because Savecur and Restcur preserve and restore the cursor position
 relative to the screen, the macros appear to do nothing. But actually,
 each executes correctly. For example, the ReposDown does the following:

 1. Savecur : saves the current position relative to the file and the
              screen

 2. Meta Up : moves the cursor to the top of the screen

 3. Up      : moves the cursor up one line, (thus scrolling the screen
              down one line)

 4. Restcur : restores the screen to the original configuration
              (appears as if nothing had happened)

 One way to achieve the desired result is to use the Mark function. The
 Mark function saves the current location in the file. The relative
 screen position is not preserved, whereas the Savecur and Restcur
 functions do save the relative screen position.

 The following macros give the desired result:

 ReposDown:=Arg Arg "tag" Mark Meta Up Up Arg "tag" Mark Up
 ReposDown:Ctrl+Up

 ReposUp:=Arg Arg "tag" Mark Meta Down Down Arg "tag" Mark Down
 ReposUp:Ctrl+Down

 The word "tag" is an arbitrary tagname for the Mark function.


 116. Copy Is a Reserved Word

 Product Version(s): 1.00   | 1.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified: 17-MAY-1989    ArticleIdent: Q42763

 The word copy is a reserved word in the Microsoft Editor. If you write
 an M extension and name it "copy", the editor will load but not
 execute your extension.

 If you name the function (for example) cpy rather than copy, it will
 work correctly.

 The following declaration incorrectly uses the reserved word "copy."
 Renaming the the function "cpy" will resolve the problem:

 flagType pascal EXTERNAL copy (argData, Parg, fMeta)
 unsigned int argData;
 ARG far *Parg;
 flagType fMeta;



 117. A C Extension to Select an Arbitrary Number of Lines of Text

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | extension highlight select
 Last Modified:  1-JUN-1989    ArticleIdent: Q43006

 To select an arbitrary number of lines of text in the Microsoft
 Editor, I must use the Arg function, then use the DOWN ARROW key until
 the desired number of lines are selected. This is inconvenient if more
 than a few lines are to be selected.

 This article provides a simple editor extension that selects the
 number of lines you specify.

 For information on loading the function, refer to the M editor
 reference manual.

 To invoke the function, use the Arg key to introduce the argument
 (i.e., the number of lines to be selected), then press the key
 assigned to the function. In Version 1.00 of M, the selected text will
 not be highlighted.   In Version 1.02 of M, the selected text will be
 highlighted, however further cursor movements will change the selected
 area without altering the highlighted area.

 ================ Make file ===============

 BASE=select
 CFLAGS=-c -W2 -Asfu -Gs
 LINKFLAGS=/NOI /NOD

 $(BASE).obj : $(BASE).c
     cl $(CFLAGS) $(BASE).c

 $(BASE).exe : $(BASE).obj
     link exthdr.obj $(BASE), $(BASE), \
     $(LINKFLAGS),clibcer.lib;

 ================ select.c ================

 #include "ext.h"
 #include <stdlib.h>

 #define TRUE    -1
 #define FALSE   0
 #define NULL    ((char *) 0)

 flagType pascal EXTERNAL Select (argData, pArg, fMeta)
 unsigned int argData;
 ARG far * pArg;
 flagType fMeta;
 {
     int  nCount, i ;

     if (pArg->argType == TEXTARG)
         if (nCount = atoi (pArg->arg.textarg.pText))
             {
             for (i = 0 ; i < nCount ; i++)
                 fExecute ("Arg Down") ;
             }

     return TRUE;
 }

 struct swiDesc  swiTable[] =
 {
     {   NULL, NULL, NULL    }
 };

 struct cmdDesc  cmdTable[] =
 {
     {"Select", Select, 0, TEXTARG},
     {NULL,  NULL, NULL, NULL}
 };

 WhenLoaded ()
 {
      SetKey("SELECT","ALT+B");
      return TRUE;
 }


 118. Cannot Use Standard Device Names as Filenames

 Product Version(s): 1.00   | 1.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified: 17-MAY-1989    ArticleIdent: Q43074

 You cannot use the standard device names (COMx, LPTx, and CON) as the
 base filename in the Microsoft Editor.

 For example, the command "M COM1.C" under DOS will attempt to open the
 communications port for editing and will hang the computer.

 This information has been tested for the following devices: COM1,
 COM2, LPT1, LPT2, CON. The different devices give slightly different
 results. COM1 and COM2 will hang the computer immediately, but the
 others will give errors or hang when the file is saved.

 The protect-mode editor behaves in the same fashion.


 119. Accessing Predefined Switches in C-Extension

 Product Version(s): 1.02   |  1.02
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | FindSwitch
 Last Modified: 17-MAY-1989    ArticleIdent: Q43436

 When writing a C extension for Microsoft Editor Version 1.02, you can
 access the predefined editor switches through the function
 FindSwitch(). FindSwitch() is intended to be used to access the values
 of the predefined editor switches, not to modify the values. Modifying
 the switches through FindSwitch() has undefined results.

 The following code fragment retrieves the value of the switch
 "tabstops" for use in your C extension:

 #include "ext.h"
       .
       .
       .

 PSWI pTabStops ;
 int  nTabStops ;
       .
       .
       .

 pTabStops = FindSwitch ("tabstops") ;
 nTabStops = *(pTabStops->act.ival) ;

 Any change to the value of the switch "tabstops" made outside your
 C extension will be reflected in the value of nTabStops inside your
 C extension.

 You can find the FindSwitch() prototype in the include file EXT.H. The
 function FindSwitch() is not available in the Microsoft Editor Version
 1.00.

 The structure, swiTable, consists of a series of structures, each
 structure describing a user-defined switch. The purpose of swiTable is
 to add user-defined, not predefined, switches. It is incorrect to name
 the predefined switches in the switch table. For that reason the
 following example is incorrect as it names "tabstops," a predefined
 switch:

 struct swiDesc swiTable [] =
  {
   {"tabstops", &nTabStops, NUMERIC | RADIX10}   /*  INCORRECT  */
   { NULL, NULL, 0}
  } ;

 Do not modify the predefined switches through the switch table. You
 can change the values of the predefined switches from within an
 editing session or in TOOLS.INI.


 120. The Editor Can Be Very Slow When MEP Memory Limit Is Pushed

 Product Version(s): 1.00 1.02
 Operating System:   OS/2
 Flags: ENDUSER |
 Last Modified: 17-MAY-1989    ArticleIdent: Q44000

 Problem:

 I have a file FOO, which is 21733 bytes long and contains 850 lines.
 When I perform the following steps the compiler appears to hang. In
 fact, however, the compiler is being forced to go to disk for its own
 memory management.

 When performing the steps described below with the README.DOC from C
 Version 5.10 (which is 64964 bytes) and running on a 16mHz machine,
 after Arg Refresh, it took almost 30 seconds for MEP to return
 control.

 This problem is due to the fact that MEP does its own memory
 management. When you do Arg Refresh, MEP must reread the buffer
 containing the modified file from disk. In addition, MEP must store
 back to disk the buffer containing the last block of text pasted to
 the file. This swapping of two large files is what causes the delay.

 Microsoft has confirmed this lack of speed to be a limitation with
 Version 1.00 and 1.02 of the Microsoft Editor. We are researching this
 problem  and will post new information as it becomes available.

 To duplicate this problem, perform the following steps:

 1. Invoke the following to run the editor:

       [C:\]m foo

 2. Make some changes to modify the buffer.

 3. Issue the following command to the editor:

       arg "bar" setfile

    The editor responds "File c:\bar does not exist, create?"

 4. Respond "y" for yes. You are now in bar's buffer.

 5. Issue the following command to read in the original contents of the
    file:

       arg arg "foo" paste

    This process should work correctly.

 6. If you now want to get rid of the new buffer, issue the following
    command:

       arg refresh

    The editor responds with something similar to the following:

       "Do you really want to delete the buffer?"

 7. Respond "y" for yes.

    The editor appears to hang.


 121. Why Syntax Errors Might Not Display While Compiling in M

 Product Version(s): 1.00   | 1.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified:  1-MAY-1989    ArticleIdent: Q43647

 Question:

 While inside the Microsoft Editor, I compiled a program that I know
 contained syntax errors. The message "Compilation Complete - return
 code is x" (where "x" is an integer value) appeared, signifying that
 an error had occurred while compiling.

 I pressed SHIFT+F3 to display those errors and the message "No more
 compilation messages" was displayed on the bottom of the screen. Why
 aren't my program's error messages displayed inside the editor?

 Response:

 You see error messages only if the compiler or linker runs correctly
 and passes the error messages in the correct format to the editor; if
 the compiler itself fails, you will not see any messages.

 Because M spawns the compiler, you could be running out of file
 handles. You know that the system has run out file handles if the
 M.MSG file is not created. Setting files=20 in your CONFIG.SYS file
 should correct the problem.

 Other possible causes for not getting error messages are as follows:

 1. You could be running out of memory. You can check this by shelling
    out of M.EXE (with SHIFT+F9) and issuing the DOS CHKDSK command to
    display the available memory.

 2. The compiler might not be able to find the specified file.
    Consider the following example, in which you invoke M.EXE as
    follows:

       C:\> M c:\c5\source\test.c

    If you compile the program with ARG COMPILE, the information line
    displays the following:

       CL /c /Zep /D LINT_ARGS test.c.

    The compiler will not find TEST.C in the current directory, so an
    error is returned.

    For more information, query on the following phrases:

       Microsoft Editor
       full path

 3. The EXTMAKE switches might have been incorrectly modified in the
    TOOLS.INI file, as in the following example:

       EXTMAKE:bas BC /Zi /O %s

    The line above is incorrect because it is missing a semicolon (;)
    at the end. The command line following the extension must be complete.
    Both the Microsoft BASIC Compiler and MASM will prompt you for
    additional information if a semicolon is not at the end of the line.

 4. Make sure the options used are valid for the compiler. In the
    following example, the option /Fa is an invalid option for the
    QCL.EXE compiler:

       QCL /Fa filename.c

 5. The compiler must be in the current path. If the compiler fails to
    execute, due to some problem external to the editor, M will
    display the ambiguous message "No more compilation messages."

    A good way to check the validity of the Compile command and to check
    for the presence of the compiler is to type in the compile line with
    all of the options directly from DOS.


 122. MEP GP Faults After Consecutive Searches.

 Product Version(s): 1.00
 Operating System:   OS/2
 Flags: ENDUSER | buglist1.00
 Last Modified:  1-JUN-1989    ArticleIdent: Q44887

 MEP gets an access violation and crashes after several searches for a
 string.

 Microsoft has confirmed this to be a problem with MEP.EXE Version
 1.00. This problem was corrected in MEP.EXE Version 1.02.

 Note: Version 1.02 of the Microsoft Editor is only available with
 FORTRAN 5.00. The documentation required for M and MEP Version 1.02
 make it impossible to release except with a major language release.

 The text file that caused MEP to fail was 54400 bytes and contained
 the string "error" in 81 different locations. To reproduce this
 problem, search for the string "error". The default keystrokes are

    Arg "error" F3

 for the first search, and the following for each additional search:

    F3

 On the 81st search, the Microsoft Editor for Protect, generates a
 General Protection Violation.


 123. Status Line Input with a Blinking Cursor

 Product Version(s): 1.00   | 1.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | GETINPUT.ARC S12311.EXE
 Last Modified: 13-SEP-1989    ArticleIdent: Q44925

 Question:

 Is it possible in the Microsoft Editor to write an extension that will
 accept a line of input from the user, preferably from the status line?

 Response:

 Version 1.02 of the Microsoft Editor offers a very convenient way to
 do this. The GetString() callback function performs exactly this type
 of input. Version 1.00 of the Editor, however, does not have such a
 callback. It is possible to put together a routine that reads user
 input using the ReadChar() function in M Version 1.00. However, since
 ReadChar() waits for the next available character, there is no
 convenient way to flash a cursor during input when using this
 approach.

 The function provided below is a status-line input routine that does
 provide a flashing cursor. It uses the KbHook() and KbUnHook()
 functions to prevent the editor from scanning the keyboard and then
 reads the keyboard directly using the kbhit() and getch() functions
 from the C run-time library.

 An example C extension that demonstrates this function is available
 in the Software\Data Library. This file can be found by searching on
 the keyword GETINPUT, the Q number of this article, or S12311.
 GETINPUT was archived using the PKware file-compression utility.

 Status-Line Input Routine
 -------------------------

 #include "ext.h"
 #include <stdio.h>
 #include <string.h>
 #include <stdlib.h>
 #include <conio.h>

 #define TRUE            1
 #define FALSE           0

 typedef unsigned        BOOL;

 char *GetInput( int BufLen, char *theBuffer );

 /* GetInput provides a means of getting user input from the status line
  * with a blinking cursor in a manner similar to M 1.02's GetString().
  * KbUnHook is used to capture keyboard input. KbHook restores normal
  * keyboard reading to the editor.
  *
  * Receives:    BufLen - Length of input buffer
  *              theBuffer - Pointer to input buffer
  *
  * Returns:     A pointer to the modified buffer, or NULL if ESC was
  *              used to cancel input.
  */
 char *GetInput(
     int             BufLen,
     char            *theBuffer )
 {
     char            Key;                        /* ASCII code of key */
     int             i = 0;                      /* Position in buffer */
     BOOL            CursorOn = TRUE;            /* State of cursor */
     int             FlashCount = 0;             /* Cursor state counter */
     int             CursorToggleCount = 100;    /* Iterations between changes
                                                    in cursor state */
     char            *r;                         /* Return pointer */

     /* Unhook the keyboard so that the editor no longer intercepts
      * keystrokes.
      */
     KbUnHook();

     /* Get keyboard input from user, stopping when ESC or ENTER is hit.
      * Characters not in the range of 32 to 127 are ignored.  Backspace
      * will work properly.  No more than (BufLen - 2) characters may
      * be entered.
      */
     do
     {
         /* Flash a cursor while waiting for the next keypress.
          */
         while( !kbhit() )
         {
             if( ++FlashCount == CursorToggleCount )
             {
                 FlashCount = 0;
                 CursorOn = !CursorOn;
                 if( CursorOn )
                 {
                     strcat( theBuffer, "_" );
                     DoMessage( theBuffer );
                 }
                 else
                 {
                     theBuffer[i] = '\0';
                     DoMessage( theBuffer );
                 }
             }
         }

         /* Snarf the key
          */
         Key = (char)getch();

         /* Handle backspace.
          */
         if( (Key == 8) && (i > 0) )
         {
             theBuffer[--i] = '\0';
             DoMessage( theBuffer );
         }

         /* Handle normal character.
          */
         if( (Key >=32) && (Key <= 127) && (i < BufLen - 2) )
         {
             theBuffer[i++] = Key;
             theBuffer[i] = '\0';
             DoMessage( theBuffer );
         }
     } while( (Key != 13) && (Key != 27) );

     /* If ESC was pressed, toss the input and NULL the input buffer,
      * else perform a little cleanup.
      */
     if( Key == 27 )
     {
         theBuffer[0] = '\0';
         DoMessage( theBuffer );
         r = NULL;
     }
     else
     {
         if( CursorOn )
             theBuffer[i] = '\0';
         DoMessage( theBuffer );
         r = theBuffer;
     }

     /* Restore normal keyboard input.
      */
     KbHook();

     return( r );
 }


 124. CALLTREE Produces No Warnings When Out of Disk Space

 Product Version(s): 1.00   | 1.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | S_C H_MASM H_Fortran S_PasCal
 Last Modified: 23-JUN-1989    ArticleIdent: Q45618

 The CALLTREE.EXE utility shipped with the Microsoft Editor (included
 with MASM, Optimizing C, FORTRAN, and Pascal) does not produce a
 warning if it runs out of disk space while writing output files. It
 simply closes the file being currently written and attempts to produce
 the next file. If the disk has no space free, the file will be created
 and closed with a length of 0 (zero) bytes. No error messages are
 produced in any case.

 Microsoft is aware of this limitation of CallTree. The error checking
 and messages features are under review and will be considered for
 inclusion in a future release.


 125. Documentation Errors in "Configuring On-Line Help" for M 1.02

 Product Version(s): 1.02   | 1.02
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | docerr
 Last Modified: 11-SEP-1989    ArticleIdent: Q46272

 There are several documentation errors in the section "Configuring
 On-Line Help" on Page 101 of the "Microsoft Editor User's Guide for MS
 OS/2 and MS-DOS Operating Systems." This is the documentation for the
 Microsoft Editor (M) Version 1.02, which first became available with
 FORTRAN Version 5.00. These errors prevent access to M help. The
 documentation says to add the following tagged section to your
 TOOLS.INI file:

    [m-help.mxt mep-help.mxt]
    helpfiles:path\file.hlp

 The tag header should be as follows:

    [m-help mep-mhelp]

 Including ".mxt" prevents M from accessing help.

 Also, in the paragraph labeled Number 2 that describes installation
 for on-line Help when running under OS/2 protected mode only, there is
 a misprint. The following sentence refers to a nonexistent file
 "MHELP.DLL":

    MHELP.DLL is an extension to the editor.

 The correct file is MHELP.PXT, so the sentence should read as follows:

    MHELP.PXT is an extension to the editor.


 126. CMD.EXE Shell Fails with Incorrect COMSPEC

 Product Version(s): 1.00 1.02
 Operating System:   OS/2
 Flags: ENDUSER |
 Last Modified: 26-SEP-1989    ArticleIdent: Q47763

 Question:

 When I attempt to shell out of the MEP editor environment via the
 Shell editor function (SHIFT+F9), why does the following message
 appear at the bottom of the screen?

    Spawn failed on C:\OS2\CMD.EXE   - No such file or directory

 Response:

 The problem is usually due to an incorrect setting of the COMSPEC
 environment variable in the CONFIG.SYS file. A faulty setting of this
 variable, which informs the operating system of the command
 interpreter's location, prevents the DOS EXEC system call from finding
 and executing the command interpreter. Use the following procedure to
 eliminate the problem:

 1. Verify that the CMD.EXE file is in the directory specified by the
    COMSPEC environment variable.

 2. Ensure the syntax correctness of the COMSPEC setting. There should
    be no spaces on either side of the equal sign, and a carriage
    return must appear immediately following the last character of the
    path and filename setting.

        Correct example:       SET COMSPEC=C:\OS2\CMD.EXE<cr>

        Incorrect examples:    SET COMSPEC = C:\OS2\CMD.EXE<cr>
                               SET COMSPEC=C:\OS2\CMD.EXE;<cr>
                               SET COMSPEC=C:\OS2\CMD.EXE<space><cr>

 Under MEP 1.02, the COMSPEC environment variable is used to locate the
 command interpreter. If the command interpreter is not found according
 to the COMSPEC variable, the "Spawn failed...." error message is
 displayed. MEP Version 1.02 does not use the PATH environment variable
 for additional searching of CMD.EXE.

 Under MEP Version 1.00, however, the PATH variable is used when the
 CMD.EXE is not found via the COMSPEC setting. Hence, if the spawn
 failure error occurs when attempting to shell out of the MEP 1.00
 environment, examine the COMSPEC setting and also verify that CMD.EXE
 is traversed by the search path of the PATH environment variable in
 the CONFIG.SYS.


 127. Curtime Function Pulls In Time Editor Was Invoked

 Product Version(s): 1.00 | 1.00
 Operating System:   OS/2 | MS-DOS
 Flags: ENDUSER | buglist1.00 fixlist1.02
 Last Modified: 28-JUL-1989    ArticleIdent: Q46790

 The Microsoft Editor Version 1.00 does not implement the Curtime
 function correctly. The manual states that the current time will be
 inserted at the cursor when this function is invoked. Actually, the
 time the editor was invoked is inserted at the cursor. To get around
 this problem, simply initialize the editor before calling the Curtime
 function.

 Microsoft has confirmed this to be a problem in Version 1.00. This
 problem was corrected in Version 1.02 of the Microsoft Editor.

 The following macro illustrates how the Curtime function is invoked.
 This macro should be placed in the TOOLS.INI file under the [m] tag.

    time:=Curtime
    time:ALT+T

 When editing a file, pressing ALT+T inserts the time that the editor
 was loaded at the cursor. To obtain the current system time, either
 invoke the Initialize function by pressing SHIFT+F8 before ALT+T, or
 change the macro as follows:

    time:=Initialize Curtime
    time:ALT+T

 Now, pressing ALT+T inserts the current system time at the cursor.

 This function is documented on Pages 30 and 96 of the "Microsoft
 Editor User's Guide," which is contained in the "CodeView and
 Utilities, Microsoft Editor, Mixed-Language Programming Guide" manual
 from the Microsoft C Optimizing Compiler Version 5.10.


 128. QUICK.INI Needs Modification for Use with M 1.02 or MEP 1.02

 Product Version(s): 1.02   | 1.02
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified: 28-JUL-1989    ArticleIdent: Q46802

 To use the QUICK.INI file provided with the Microsoft M Editor Version
 1.02 as the TOOLS.INI file, it is necessary to make two modifications
 to the file. Without the modifications the editor gives the following
 error messages:

    Argcompile is not an editor function               press any key...
    Help is not an editor function                     press any key...

 To get past the Argcompile error message, add the following line to
 the TOOLS.INI file before the Argcompile:F5 line:

    Argcompile:=arg compile

 The Argcompile macro is also defined in the TOOLS.PRE file provided
 with the editor. The Help:F1 line is a leftover from previous versions
 of the editor and is not implemented in this version. To eliminate the
 Help error message, either delete or comment out the Help:F1 line.


 129. Documentation Error for "Mark" Functions in M User's Guide

 Product Version(s): 1.02   | 1.02
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | docerr
 Last Modified:  2-AUG-1989    ArticleIdent: Q47236

 On Page 179 of the Version 1.02 "Microsoft Editor for MS OS/2 and
 MS-DOS Operating Systems: User's Guide," there is a documentation
 error. In the section of the reference table describing the "Mark"
 function, the marker deletion and marker definition descriptions are
 reversed. To define a marker at the cursor position, the correct
 syntax is Arg Arg textarg Mark. To delete a marker definition, the
 syntax is Arg Arg textarg Meta Mark. The entries SHOULD appear as
 follows:

    Entry                         Function
    -----                         --------

    Arg Arg textarg Mark          Defines a file marker at the
                                  initial cursor position. This
                                  does not record the file marker
                                  in the file specified by the
                                  markfile switch, but allows you
                                  to refer to this position as
                                  textarg.

    Arg Arg textarg Meta Mark     Deletes a marker definition.

 On Page 39, the reference to Arg Arg textarg Mark is correct.


 130. CopyBox Function Doesn't Work Across Files

 Product Version(s): 1.00   | 1.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | S_C S_Pascal H_Fortran H_MASM
 Last Modified: 26-SEP-1989    ArticleIdent: Q47765

 CopyBox is a C-extension function for the Microsoft editor that is
 designed to copy square regions of text from one location to another,
 including to another file.

 This function works properly when copying to the same file, but fails
 when copying to another file. The function appears to work
 successfully, but the copied text does not appear in the target file.
 This lack of functionality has been corrected in Version 1.02 of the
 editor.

 You can work around this problem by using the GetLine and PutLine
 functions. A line can be read from the source file, trimmed to get the
 proper portion of the line, and then written to the target file. This
 procedure must be followed for each line of the box to copy.


 131. Getting SYS2070 While Using MEP

 Product Version(s): 1.02
 Operating System:   OS/2
 Flags: ENDUSER | MEP
 Last Modified: 26-SEP-1989    ArticleIdent: Q47767

 Problem:

 When I start MEP, I receive the following error:

      |---------------------------------------------------------------|
      | SYS2070: The system could not demand load the                 |
      | application's segment. MSHELP HELPGETINFO is in error.        |
      | For additional detailed information also see message SYS0127. |
      |---------------------------------------------------------------|
      |                     End the program                           |
      |_______________________________________________________________|

 After selecting "End the program," I receive the following message:

    A non-recoverable error occurred.
    The process ended.

 Response:

 The MEP program is picking up an old version of MSHELP.DLL. The likely
 source is from the OS/2 Presentation Manager Toolkit. To correct this
 problem, replace the old MSHELP.DLL with the current MSHELP.DLL.

 If there is no MSHELP.DLL on the LIB path, then MEP loads and seems to
 function correctly, but there will be no help available.


 132. Possible Explanation for "Cannot Close This Window" Error

 Product Version(s): 1.00   | 1.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified: 26-SEP-1989    ArticleIdent: Q47770

 Problem:

 Under M Version 1.00 I have two horizontal windows open, each viewing
 separate files. When I attempt to close a window (META+WINDOW or F9+F6),
 I sometimes get the error message "Cannot close this window." Under
 seemingly similar conditions, this error message does not occur and
 the window closes properly.

 Response:

 This message occurs when you attempt to close a window that contains
 modified text. If you want to abandon edits on the file, you can
 reread the file using SHIFT+F7 and then successfully close the window.


 133. ECH.EXE Utility Is Used Internally by the Microsoft Editor

 Product Version(s): 1.00   | 1.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified: 26-SEP-1989    ArticleIdent: Q47772

 ECH.EXE is a character echoing utility that is included with the
 Microsoft Editor (M) Version 1.00. This utility is mentioned in the
 appendix of the editor's user guide simply because it is an external
 file.

 The file is used with the Setfile command using wildcards. When
 issuing the command "Arg *.* Setfile", M will use ECH.EXE to display
 the files in alphabetical order. If ECH.EXE is not found in the
 current path, the message "NO MATCHING FILES" is generated.

 If this error message occurs in a subdirectory that does contain
 files, then ECH.EXE is not being found.

 M 1.02 does not use this external file. The utility has been
 incorporated into the editor.


 134. Invoking M or MEP with the /D Switch Prevents Initialization

 Product Version(s): 1.00 1.02 | 1.00 1.02
 Operating System:   MS-DOS    | OS/2
 Flags: ENDUSER | reinitialize
 Last Modified: 26-SEP-1989    ArticleIdent: Q48687

 Invoking the Microsoft M editor with the /D switch to prevent it from
 initializing from the TOOLS.INI file also prevents the Initialization
 function (SHIFT+F8) from reading the TOOLS.INI file.

 There is currently no workaround for this designed limitation other
 than to exit the editor and re-invoke M without using the /D switch.


 135. Microsoft Editor (M) Version 1.02: On-Line Help Not Loaded

 Product Version(s): 1.02
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 26-SEP-1989    ArticleIdent: Q48130

 Trying to access on-line help after initializing (reloading the editor
 settings from TOOLS.INI) generates the following message:

    Online Help Not Loaded

 The following steps will demonstrate the problem:

 1. M (Start the editor, with or without a file.)

 2. F1 (Request on-line help -- success.)

 3. SHIFT+F8 (Initialize editor settings.)

 4. F1 (Request on-line help -- receive error message.)

 Microsoft is researching this problem and will post new information
 as it becomes available.


 136. Invalid Arg Filename Followed By F2 Causes Screen Error

 Product Version(s): 1.00   | 1.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | buglist1.00
 Last Modified: 26-SEP-1989    ArticleIdent: Q48871

 When trying to read in a file with the Arg Setfile function, an
 improper filename returns an operating system error. If the Microsoft
 editor (M) is in split-screen mode, any horizontal divider bars are
 lost in MEP. The error contains the two following lines, which cause
 the screen to scroll one position erroneously:

    Next filSYS1041: The name specified is not recognized as an
    internal or external command, operable program, or batch file.

 In M, screen integrity is preserved, but the following error is
 returned:

    Bad command or filename.

 For example, invoke arg (ALT+A) to start an argument and enter about
 20 or so shifted numbers (e.g. ^&%$&^%$^%$#^%$#^%$@%(^&*(*^&&*), and
 then invoke Setfile (F2).

 The screen becomes corrupted and the next keystroke may crash the
 editor with an integer divide by 0 (zero).

 Microsoft has confirmed this to be a problem with the Microsoft Editor
 Version 1.00. We are researching this problem and will post new
 information as it becomes available.


 137. How to Search and Replace Control Characters with M Editor

 Product Version(s): 1.00 1.01 1.02 | 1.00 1.01 1.02
 Operating System:   MS-DOS         | OS/2
 Flags: ENDUSER |
 Last Modified: 10-OCT-1989    ArticleIdent: Q49010

 To search for and replace control characters with the M editor, use
 the following procedure:

 1. Invoke the search and replace function (CTRL+\).

    The editor prompts with "Query Search String:".

 2. Invoke the quote function (CTRL+P).

 3. Type the control character and press ENTER.

    The editor prompts with "Replace string:".

 4. Invoke the quote function.

 5. Type the control character.


 138. Background Color Greater Than Seven Causes Region to Blink

 Product Version(s): 1.00 1.02 | 1.00 1.02
 Operating System:   MS-DOS    | OS/2
 Flags: ENDUSER |
 Last Modified: 26-FEB-1990    ArticleIdent: Q57585

 It is possible to configure both the background and foreground color
 of the various text items that the Microsoft Editor (M) displays. If
 you attempt to set the background color to a color greater than seven,
 the color region blinks. This behavior, however unusual, is expected,
 and is documented in the "Microsoft Editor for MS OS/2 and MS-DOS
 User's Guide" on Page 87.

 The following M Editor color switches control the colors of various
 text display regions:

    Switch        Controls
    ------        --------

    hgcolor       Background and text color
    hgcolor       Search highlight colors
    infocolor     Information message colors
    selcolor      Cursor highlight colors
    stacolor      Status line colors
    wdcolor       Window border colors

 The following are the colors these switches can be set to:

    Black                 0
    Blue                  1
    Green                 2
    Cyan                  3
    Red                   4
    Magenta               5
    Brown                 6
    Light Gray            7
    Dark Gray             8   Will blink when set to background
    Light Blue            9   Will blink when set to background
    Light Green           A   Will blink when set to background
    Light Cyan            B   Will blink when set to background
    Light Red             C   Will blink when set to background
    Light Magenta         D   Will blink when set to background
    Light Yellow          E   Will blink when set to background
    White                 F   Will blink when set to background

 These colors are set in your TOOLS.INI as follows:

                +------------------- Background Color
                |
                v

    colorswitch:BF <---------------- Foreground Color

 The following example, inserted in your TOOLS.INI, sets the foreground
 and background colors of the editing windows (90 percent of the
 screen):

    fgcolor:62 < ------------------- Green

            ^
            |
            +----------------------- Brown


 139. M Editor Version 1.00 Does Not Clear Compiler Error Buffer

 Product Version(s): 1.00   | 1.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER  | buglist1.00 fixlist1.02
 Last Modified: 11-OCT-1989    ArticleIdent: Q49536

 When using the compile function from within the editor, the errors
 stored in memory are not cleared. Thus, if you do not go through all
 errors with the nextmsg function, the errors remain even if another
 compile is done. Therefore, if the second compile process does not
 produce any errors, the errors from the previous compile show up and
 put the cursor on an unpredictable line.

 To work around this problem, make sure you look at all of your error
 messages from each compile.

 Microsoft has confirmed this to be a problem with the Microsoft Editor
 Version 1.00. This problem was corrected in Version 1.02 of the
 Editor.


 140. Configuring On-Line Help for M 1.02

 Product Version(s): 1.02   | 1.02
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified: 30-NOV-1989    ArticleIdent: Q49576

 The following is the correct way to configure on-line help for the
 Microsoft Editor (M) Version 1.02 for both MS-DOS (real mode) and
 OS/2 (protected mode).

 Copy files from the distribution disk, as follows:

 1. Under MS-DOS real mode, copy M.HLP and MHELP.MXT to any directory
    specified in the PATH environment variable in the AUTOEXEC.BAT
    file.

 2. Under OS/2 protected mode, copy M.HLP and MHELP.PXT to any
    directory specified in the PATH environment variable in the
    STARTUP.CMD file. Also copy MSHELP.DLL to any directory listed in
    the LIBPATH variable in the CONFIG.SYS file.

 3. For both DOS and OS/2, perform both the preceding steps.

 Other Microsoft products include .HLP files that the editor can
 read. If you want to add additional .HLP files to help, you must
 include the following tagged section in your TOOLS.INI:

 1. Include the following tagged section:

       [M-MHELP]                    ; For DOS real mode

       [MEP-MHELP]                  ; For OS/2 protected mode

       [M-MHELP MEP-MHELP]          ; For both DOS and OS/2

 2. Add the following switch to load in the help files:

       Helpfiles: M.HLP .BAS:C:\QB\QB.HLP .C.H:C:\QC\QC.HLP .PAS:C:\QP\QP.HLP

    This is an example of help files that are loaded upon startup of M
    or MEP. Help searches QB.HLP first when the file has a .BAS
    extension, QC.HLP when the current file has a .C or .H extension,
    and QP.HLP when the current file has a .PAS extension. Please note
    that these help files come with their respective language, not M
    1.02.

 For more information on this topic, refer to the Microsoft Editor for
 MS OS/2 and MS-DOS Operating Systems: User's Guide" that accompanies
 with M 1.02.


 141. Undocumented Switch "Sethelp" for M Version 1.02

 Product Version(s): 1.02   | 1.02
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | docerr
 Last Modified: 24-JAN-1991    ArticleIdent: Q50012

 If you have the M (or MEP) Editor version 1.02 configured for online
 help, you can use the undocumented "Sethelp" switch to load additional
 help files within the editor by using the following syntax:

    Arg textarg Sethelp      ;ALT+A textarg ALT+S

 Textarg corresponds to the full pathname of the .HLP file you want to
 load. By default, the sethelp function is mapped ALT+S.

 For example, load the QC.HLP help file that comes with QuickC with the
 following command:

    ALT+A D:\QC\QC.HLP ALT+S

 Now you could place the cursor on printf (or any other C language item
 that is in the Help file) and press F1 to get help on that topic.


 142. Printing Double Quotation Marks from within an M Editor Macro

 Product Version(s): 1.00 1.02 | 1.00 1.02
 Operating System:   MS-DOS    | OS/2
 Flags: ENDUSER |
 Last Modified: 30-NOV-1989    ArticleIdent: Q50223

 To get double quotation marks ("") printed from within a macro in the
 M Editor, use the backslash key (\) followed by the double quotation
 marks (""). The following example (placed in the correct section of
 the TOOLS.INI file) demonstrates how this is done:

    text:=arg "say \"hello\"" paste
    text:alt+z

 In this case, pressing ALT+Z inserts the following string into your
 text, with the double quotation marks around the word hello.

    say "hello"


 143. Controlling the Use of Tabs in the Microsoft Editor

 Product Version(s): 1.00 1.02 | 1.00 1.02
 Operating System:   MS-DOS    | OS/2
 Flags: ENDUSER |
 Last Modified: 30-NOV-1989    ArticleIdent: Q50588

 The Microsoft Editor (M) provides the following two ways of using tab
 characters:

 1. Treat tabs as real characters.

 2. Convert each tab into a series of spaces. This is controlled
 through the use of the "realtabs" switch. Other switches may also
 effect the way tabs appear to be handled by the editor.

 The following chart, taken from Section 7.2.6 of "Microsoft Editor for
 MS OS/2 and MS-DOS User's Guide" describes the switches dealing with
 tabs.

 1. realtabs

    On by default, controls whether or not tabs are treated as real tab
    characters.

 2. entab

    Controls the extent to which the editor converts a series of tabs
    and spaces to tabs when saving a file. The following are the valid
    choices:

       0 - The editor does not replace spaces by tabs. If realtabs is off,
           tabs are converted to spaces.

       1 - (default) The editor can replace a series of tabs and spaces by
           tabs when the tabs fall outside of quoted strings.

       2 - The editor will replace all series of tabs and spaces with
           tabs.

    Note: The entab switch only effects the lines you modify during the
    current editing session.

 3. filetab

    Controls the meaning of tab characters on a disk file. If realtabs
    is on, the filetab switch determines tab alignment. If realtabs is
    off, the filetab switch determines how the editor translates tab
    characters to spaces when a line of text is modified.

    If entab, as described above, is set to 1 or 2, filetab also
    determines how the editor translates spaces to tabs when you save
    the file to disk.

    Note: The filetab switch only effects the lines you modify during
    the current editing session.

 4. tabalign

    When off (the default), the cursor may be placed anywhere inside a
    column of a tab character. If turned on, along with realtabs, the
    cursor is placed to the first column position of tab characters.

 5. tabstops

    Determines the size of columns associated with the TAB and BACKTAB
    ( SHIFT+TAB) keys. This only moves the cursor and has no effect on
    the actual tab character. The default value is 4.

    The following example sets up tabs so that they act the same way
    they do in other editors, such as QuickC or Word:

       realtabs:yes
       tabalign:yes
       graphic:tab
       trailspace:yes
       filetab:4

 The trailspace switch is needed to use tabs on blank lines. The
 tabdisp switch may also be used with realtabs to make the tab
 characters visible on the screen.


 144. Mhelp Function Is Always Assigned to SHIFT+F1

 Product Version(s): 1.02   | 1.02
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified: 17-JUL-1990    ArticleIdent: Q50642

 In the Microsoft Editor (M) Version 1.02, the mhelp function is like
 any other function that can be assigned to any key. However, mhelp is
 always assigned to SHIFT+F1 unless this key is unassigned using the
 unassigned keyword in the m-mhelp block of the TOOLS.INI file.

 It is perfectly acceptable to assign the mhelp to any key, and it will
 work properly with that keystroke. However, in addition to the newly
 assigned key, the mhelp function is always assigned to SHIFT+F1. This
 assignment can be taken out by placing the following line in the
 [M-MHELP] section of the TOOLS.INI file:

    [M-MHELP]
    unassigned:shift+f1


 145. Adding helpwindow in TOOLS.INI as a Switch

 Product Version(s): 1.02   | 1.02
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified: 30-NOV-1989    ArticleIdent: Q50644

 To get the Microsoft Editor (M) to recognize helpwindow as a switch in
 the TOOLS.INI file, the switch must be under the [M-MHELP] or
 [MEP-MHELP] tag section. The example below shows what a TOOLS.INI file
 might look like:

    [M-MHELP MEP-MHELP]
    nohelpwindow:

    [M MEP]
      .
      .

 The helpwindow switch can also be set in the environment by typing the
 following:

    <arg> nohelpwindow: <assign>


 146. Searching in the M Editor with Regular Expressions

 Product Version(s): 1.00 1.02 | 1.00 1.02
 Operating System:   MS-DOS    | OS/2
 Flags: ENDUSER |
 Last Modified: 30-NOV-1989    ArticleIdent: Q51324

 Question:

 When using the M Editor, every time I execute a search command using a
 Regular Expression, the editor takes the command literally and doesn't
 recognize the textarg as a Regular Expression. How can I get this
 search to work?

 Response:

 The correct method is as follows:

       arg arg textarg <search_function>

               arg -> ALT+A
           textarg -> A Regular Expression (i.e., ^S[te].*end)
 <search_function> -> Psearch, Msearch, Replace, Qreplace

 For more information, see Chapter 5, Pages 51-63, in the "Microsoft
 FORTRAN Microsoft Editor User's Guide."


 147. mgreplist Incorrectly Documented As megreplist in Example

 Product Version(s): 1.02
 Operating System:   MS-DOS
 Flags: ENDUSER | docerr
 Last Modified: 15-MAR-1990    ArticleIdent: Q51622

 The examples given on Pages 180 and 181 of the FORTRAN "Microsoft
 Editor User's Guide" incorrectly identifies the megreplist command as
 mgreplist. The documentation shows the following:

    megreplist:="DATA.FIL *.FOR $INCLUDE:*.H"

 This should be the following:

    mgreplist:="DATA.FIL *.FOR $INCLUDE:*.H"

 The megreplist macro does not exist and should be changed to
 mgreplist.

 The example above sets mgreplist to a series of files to be searched
 when Mgrep is called. If the textarg string (specified as an argument
 to Mgrep) is found in any of these files, the instance will be
 reported in the pseudo file <compile>. All succeeding calls to Mgrep
 will reset this file.

 The following are the files that are searched in the above example:

 1. DATA.FIL.

 2. Any file in the current directory with a .FOR extension.

 3. Any file along the INCLUDE environment variable path with a .H
    extension.


 148. C Extensions: Link Errors on __acrtused and _main Explained

 Product Version(s): 1.00    | 1.02
 Operating System:   MS-DOS  | OS/2
 Flags: ENDUSER |
 Last Modified: 21-DEC-1989    ArticleIdent: Q51636
 Question :

 I am writing a C extension for the Microsoft Editor (M). When I link,
 I get the following error message:

    c:\usr\lib\CLIBCE.LIB(dos\crt0.asm)
            error  L2044:  __acrtused
            symbol multiply defined, use /NOE  pos
            1CC Record type: 53E4

    LINK : error L2029: Unresolved externals:
    _main in file(s):  c:\usr\lib\CLIBCE.LIB(dos\crt0.asm)
    Two errors were detected.

 I am compiling and linking as follows:

    cl /c /Gs /Asfu c_extension.c
    link /NOI /NOE exthdr.obj c_extension.obj, c_extension;

 These options seem to be correct according to the Editor manuals. Why
 am I getting these linker errors?

 Response:

 The linker gives these error messages if you are linking with a
 run-time function that must be initialized from the C start-up source
 code. This start-up source code is not used within a C extension.

 The art of writing C extensions for M Version 1.00 is documented in
 Chapter 8 of the Editor section of the "CodeView and Utilities,
 Microsoft Editor, Mixed-Language Programming Guide," which is included
 with C 5.00, C 5.10, Pascal 4.00, FORTRAN 4.10, and MASM 5.10.
 References to M Version 1.02 extensions are discussed in Chapter 8 of
 the "Microsoft Editor User's Guide," which came with FORTRAN 5.00.

 Please contact Microsoft Product Support Services at (800) 454-2030 to
 obtain an application note that discusses further techniques of writing C
 extensions for the Microsoft Editor.


 149. U1013 Link: Error 2: Not Enough Memory for Exec in M

 Product Version(s): 1.00 1.02
 Operating System:   MS-DOS
 Flags: ENDUSER | s_nmake s_make
 Last Modified: 23-JAN-1991    ArticleIdent: Q57653

 Question:

 In DOS, I am spawning either MAKE or NMAKE within the Microsoft Editor
 (M), and I receive an error message from the Editor on the status line
 saying "U1013 : Link file.obj: Error 2." What does this error mean and
 how do I get around it?

 Response:

 The U1013 error means that one of the procedures called by MAKE or
 NMAKE returned a nonzero error code. In this case, the error can be
 understood as M's equivalent of a "Not enough memory for exec" error,
 meaning that there is not enough memory for the parent process to
 execute a child process. The error typically occurs when you spawn
 either MAKE or NMAKE from within the Editor, the compilation is
 complete, and the link process is beginning.

 If you receive this error, you may be able to free up memory by
 removing any TSRs and unnecessary device drivers. However, the best
 workaround would be to use MAKE or NMAKE to link your file outside of
 M, because M will have problems exec'ing the linker in any sizable
 application due to the size of LINK and MAKE.


 150. Mgrep Can Skip Occurrences of Pattern When Using Mgreplist

 Product Version(s): 1.02   | 1.02
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | buglist1.02
 Last Modified: 16-JAN-1990    ArticleIdent: Q57705

 "Mgrep" may find every other occurrence of a search string when used
 to search a list of input files defined my the "mgreplist" macro.

 Mgrep searches all files defined by the mgreplist macro, then writes
 the location of a match to the <compile> pseudo file. When using
 either regular expression search patterns or standard search strings,
 mgrep may post every other occurrence of the matched string to the
 <compile> pseudo file. This also causes SHIFT+F3 to display every
 other match in the file being searched.

 To see the problem, set the mgreplist:="test.dat" where TEST.DAT
 contains the following:

    #include1
    #include2
    #include3
    #include4
    #include5
    #include6
    #include7
    #include8
    #include9
    #include10
    #include11
    #include12

 Invoke the mgrep search on the string "include" and then press
 SHIFT+F3 to view the next match. You will see that only every other
 occurrence of "include" is found. Also, if you view the <compile>
 pseudo file it will only contain a list every other occurrence of
 "include".


 151. M "Keyboard" Switch Doesn't Work As Documented

 Product Version(s): 1.02
 Operating System:   MS-DOS
 Flags: ENDUSER | S_FORTRAN buglist1.02
 Last Modified: 20-JAN-1990    ArticleIdent: Q57750

 The Microsoft Editor (M) Version 1.02 "keyboard" switch, documented on
 Page 198 of the the "Microsoft Editor User's Guide for MS OS/2 and
 MS-DOS Operating Systems," does not work as documented.

 The switch was implemented to allow control of which BIOS keyboard
 calls are used to get keystrokes. The "compatible" setting uses the
 standard INT 16H, AH = 0 to get keystrokes. The "enhanced" setting
 uses INT 10H, allowing the F11 and F12 keys to be read, and allowing
 you to use old versions of packages that may fail when your keyboard
 is treated as enhanced.

 If you set the "keyboard" option in your TOOLS.INI file by adding a
 line reading

    keyboard:"compatible"

 and then bring up the editor, M accepts the setting, but fails to set
 correctly. If you press SHIFT+F1 for help and choose Current
 Assignments, the list of current key assignments is given. The
 keyboard switch will now be set to the following:

    keyboard::enhanced

 Note the double colon, and that the compatible option has been
 changed to enhanced.

 If you try to set the option within the editor by entering the
 following, the editor returns the same options as above:

    ALT+A keyboard:compatible ALT+=

 Microsoft has confirmed this to be a problem in the Microsoft Editor
 Version 1.02. We are researching this problem and will post new
 information here as it becomes available.


 152. Incorrect Message from "searchall" with Regular Expressions

 Product Version(s): 1.02   | 1.02
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | M MEP buglist1.02
 Last Modified: 23-JAN-1990    ArticleIdent: Q57932

 The Microsoft Editor searchall function (that is, SHIFT+F6) may return
 the following invalid error message when using regular expressions:

    +'pattern' not found

 'pattern' is the actual regular expression for which the search was
 requested.

 In this situation, searchall still finds all occurrences of the search
 pattern correctly -- only the message is incorrect.


 153. Version 1.02 of M and MEP Incorrectly Reports Version As 1.2

 Product Version(s): 1.02   | 1.02
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | docerr
 Last Modified: 26-FEB-1990    ArticleIdent: Q58687

 If you access help for the Microsoft Editor (M/MEP) Version 1.02, the
 version is incorrectly displayed as 1.2, rather than 1.02. This
 incorrect version number appears in both the internal online help and
 when invoking help from the command line with the /? switch.

 The following information is incorrectly displayed when using the /?
 command-line switch for help:

    Microsoft (R) Editor Version 1.2
    Copyright (C) Microsoft Corp 1987-1989. All rights reserved
    Usage: [/D] [/e cmd-string] [/m mark] [/r] [[/t] filename]*


 154. Quote Function (CTRL+P) Can Fail to Work Properly

 Product Version(s): 1.00 1.02 | 1.00 1.02
 Operating System:   MS-DOS    | OS/2
 Flags: ENDUSER | buglist1.00 buglist1.02
 Last Modified: 26-FEB-1990    ArticleIdent: Q58720

 The Quote function (CTRL+P) in conjunction with CTRL+I or CTRL+T fails
 to display the valid character associated with that key sequence. For
 CTRL+P with CTRL+I, a space character (Hex 20) results instead of the
 correct foreground color rectangle with a background color dot (hex
 09). For CTRL+P with CTRL+T, a lowercase "a" with an accent mark (hex
 A0) results instead of the paragraph sign (hex 14).

 The Quote function reads one keystroke from the keyboard and treats it
 literally. This is useful for inserting text into a file that happens
 to be assigned to an editor function. For example, the key sequence
 Quote (CTRL+P) CTRL+A displays a happy face character.

 For the Quote CTRL+I sequence, the only workaround is to use a Quote
 TAB key sequence. This puts the correct hex value in that position
 (09H), but the correct character is not displayed and the tab is
 treated as a tab by the M Editor.

 For the Quote CTRL+T sequence, there is no workaround.

 Microsoft has confirmed this to be a problem with the M Editor Versions
 1.00 and 1.02. We are researching this problem and will post new
 information here as it becomes available.



 155. Replacing Normal String Takes Longer Than Regular Expression

 Product Version(s): 1.00 1.02 | 1.00 1.02
 Operating System:   MS-DOS    | OS/2
 Flags: ENDUSER | buglist1.00 buglist1.02
 Last Modified: 15-MAR-1990    ArticleIdent: Q59085

 Replacing a regular expression takes less time than replacing a normal
 string in the Microsoft M Editor, Versions 1.00 and 1.02. To
 demonstrate the time difference, perform test replacements in the
 following manner:

 1. Load the M Editor with a large file -- greater than 5000 lines.

 2. Perform and time a replacement on a regular expression, one that
    fails to match in the file, for example:

       arg arg CTRL+L     zzzz   <- search for this regular expression
                          zzzz   <- replace with this regular expression

 3. Perform and time a replacement on a normal string (one that fails
    to match in the file), for example:

       arg CTRL+L     zzzz   <- search for this string
                      zzzz   <- replace with this string

 The string replacement may take twice as long as the
 regular-expression replacement. To obtain the higher replace speed,
 use the regular-expression replacement (arg arg CTRL+L) even when you
 are not fully using the regular-expression syntax.

 Note that a psearch on a regular expression psearch is NOT quicker
 than a psearch on a normal string.

 Microsoft has confirmed this to be a problem in Versions 1.00 and
 1.02. We are researching this problem and will post new information
 here as it becomes available.

 For details on regular expression, refer to the "Microsoft Editor
 User's Guide," Chapter 5, "Regular Expressions."


 156. Incorrect Version Numbers Cause Tagged Sections to Be Ignored

 Product Version(s): 1.00 1.02 | 1.00 1.02
 Operating System:   MS-DOS    | OS/2
 Flags: ENDUSER | pwb
 Last Modified: 25-MAY-1990    ArticleIdent: Q59256

 With the Microsoft Editor (M) or the Programmers WorkBench (PWB), it
 is possible to include information in your TOOLS.INI file that is
 specific to the operating system you are using. For information on how
 to create sections with tags, see the "Microsoft Editor User's Guide,"
 Section 7.5.1. However, you must be sure to include a trailing 0
 (zero) on the label for OS/2 versions 1.10 or 1.20. Failure to do so
 causes these sections to be ignored by the Editor.

 The following headers cause the tagged sections to be ignored when
 running under OS/2 version 1.10:

    [M-10.0 M-10.1]
    fgcolor:0B
    hgcolor:30
    stacolor:0E

    [M-3.30 M-10.0R M-10.1R]
    fgcolor:0E
    hgcolor:E0
    stacolor:0B

 The tags must be rewritten as follows:

    [M-10.0 M-10.10]
    fgcolor:0B
    hgcolor:30
    stacolor:0E

    [M-3.30 M-10.0R M-10.10R]
    fgcolor:0E
    hgcolor:E0
    stacolor:0B

 Furthermore, the tagged sections must not be placed in the middle of
 an [M] or [M MEP] tagged section. They must be placed before or after
 the [M] or [M MEP] sections. Failure to do this causes information
 located below these sections to be ignored in the DOS compatibility
 box.

 Note: For the PWB, the above examples would change to PWB-xxxx instead
 of M-xxx.


 157. Unassigning Help Keystrokes Must Be Done Under

 Product Version(s): 1.02   | 1.02
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified: 13-MAR-1990    ArticleIdent: Q59494

 It is possible with the Microsoft Editor Version 1.02 to disable
 an assigned keystroke so that it invokes no editor function at all.
 The keystroke can then be assigned to any other function or macro. By
 putting the disable information in the M Editor section of the
 TOOLS.INI file, the changes will be in effect whenever the Editor is
 invoked. For further information, see the Version 1.02 edition of
 "Microsoft Editor User's Guide," Section 6.2.3, Page 70.

 To regularly disable a keystroke that has been assigned to any preset
 Editor HELP function, such as F1 or SHIFT+F1, the command must be
 placed under the [M-MHELP MEP-MHELP] tag in TOOLS.INI -- not under the
 [M MEP] tag.

 For example, to disable the keystroke for F1, include the following
 line in your TOOLS.INI file:

    unassigned:F1

 Placing this line under the section tagged [M MEP] rather than the
 [M-MHELP MEP-MHELP] tag causes this command to be ignored. This is
 also applicable to the undocumented "sethelp" function, whose default
 keystroke is ALT+S. You can unassign ALT+S, as well as reassign a
 different keystroke to "sethelp", but it must be done under the
 [M-MHELP MEP-MHELP] tag.


 158. Using RIGHT ARROW on Dialog Line Locks Keyboard or GP Faults

 Product Version(s): 1.02   | 1.02
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | buglist1.02
 Last Modified: 15-MAY-1990    ArticleIdent: Q59527

 Manipulating text on the dialog line must be handled differently in
 the Microsoft Editor (M) Version 1.00 than in 1.02. If you use an M
 Version 1.00 procedure in M Version 1.02 under DOS, the keyboard will
 lock up and alternating screens of jumbled characters may appear on
 the screen. Under OS/2, you will get a GP fault resulting in the
 termination of MEP by the operating system.

 The problem can be observed by using the following steps from within
 the editor:

 Note: Remember that under DOS your machine will hang!

 1. Press ALT+A to invoke the <arg> function.

 2. Type any character (for example, the letter "d").

 3. Hold down the RIGHT ARROW key. When the text in the dialog line has
    scrolled off the left side of the screen, in M 1.00 the editor will
    issue a beep. In M 1.02, the machine will lock in DOS or GP fault
    in OS/2. This problem occurs even if you omit Step 2, but it is
    more difficult to see the error.

 To retain the same functionality in M 1.02, instead of using the RIGHT
 ARROW key to move the cursor to the right, use the SPACEBAR. Using
 the SPACEBAR rather than the RIGHT ARROW key allows you to take
 advantage of the maximum arg line limit without the error.

 Microsoft has confirmed this to be a problem in Version 1.02. We are
 researching this problem and will post new information here as it
 becomes available.


 159. Reference to "Push" Function Incorrect Editor User's Guide

 Product Version(s): 1.00   | 1.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | docerr
 Last Modified: 17-JUL-1990    ArticleIdent: Q60339

 On Page 61 of the "Microsoft Editor User's Guide" for Microsoft C
 5.10, there is a documentation error. It is stated that the Boolean
 switch Savescreen is "for use with the Push and Exit functions." Since
 there is no "Push" function, this should read "for use with the Shell
 and Exit functions."


 160. Prototype in User's Guide for tglcase() Is Incorrect

 Product Version(s): 1.02    | 1.02
 Operating System:   MS-DOS  | OS/2
 Flags: ENDUSER | docerr
 Last Modified: 15-APR-1990    ArticleIdent: Q60487

 In the sample program for a C extension on Page 126 of the "Microsoft
 Editor User's Guide" for Microsoft FORTRAN 5.00 and Microsoft BASIC
 PDS Version 7.00, the prototype for tglcase() is incorrect.

 The function is prototyped as follows:

    flagType pascal EXPORT tglcase (unsigned int, ARG far *, flagType);

 It should be as follows:

    flagType pascal EXTERNAL tglcase (unsigned int, ARG far *, flagType);

 Note: The word EXTERNAL replaces EXPORT.


 161. Creating a Compile Window Macro for the M Editor Version 1.02

 Product Version(s): 1.02   | 1.02
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified: 27-JUL-1990    ArticleIdent: Q63950

 The macro below creates a "compile window" in either the M or MEP
 Editor version 1.02 when you press ALT+C. Note that a compile window
 is helpful for viewing general compilation errors and errors generated
 from utilities that were invoked.

 The following macro, CompWindow, can be added to the [M] or [MEP]
 tagged section of the TOOLS.INI file to create a compile window:

    CompWindow:= savecur home meta down  \
                 up up up up arg window  \
                 window arg "<compile>" setfile  \
                 window restcur

    CompWindow: alt+c

 The CompWindow macro above creates a compile window by performing the
 following steps:

 1. Use the "savcur" function to save the current position of the
    cursor.

 2. Use the "home" function to place the cursor in the upper-left
    corner of the screen. This function guarantees that the cursor will
    be in a left-most position when the compile window is created.

 3. Use the "meta down" function to move the cursor to the bottom of
    the window without changing the column position.

 4. Use "up up up up arg window" functions to create a horizontal
    window four lines above the bottom of the screen. A larger compile
    window can be created by adding more "up" functions to this line in
    the macro.

 5. Use the 'arg "<compile>" setfile' function to create a
    dynamic-compile log. More information concerning the
    dynamic-compile log can be found on Pages 47-48 of the "Microsoft
    Editor User's Guide."

 6. Finally, the original position of the cursor is restored in the
    original window by using the "window restcur" functions.

 7. The macro is assigned to the ALT+C keystroke, although any unused
    keystroke may be used.

 Error messages will now be displayed in the compile window when
 running a compilation or invoking a utility.


 162. C 6.00 UNDEL.EXE Is Not Compatible with the Microsoft Editor

 Product Version(s): 1.00 1.02 | 1.00 1.02
 Operating System:   MS-DOS    | OS/2
 Flags: ENDUSER |
 Last Modified: 25-JUL-1990    ArticleIdent: Q64024

 If backup copies of files are stored in the \DELETED subdirectory by
 the M Editor, typing "undel" should bring up a listing of backup
 copies. However, if the C 6.00 version of UNDEL.EXE is used, the
 following message will be displayed: "

    0(0) bytes in 0 deleted files.

 The C 5.10 version of UNDEL.EXE will successfully bring up a listing
 of backup copies saved by either the M Editor or the Programmer's
 WorkBench (PWB).

 This problem can be reproduced by setting the text backup switch in
 the M section of the TOOLS.INI file to "undel". After saving various
 copies, backups are added to the \DELETED subdirectory and a listing
 can be brought up by using the C 5.10 UNDEL.EXE. Using the C 6.00
 version of UNDEL.EXE causes the erroneous message listed above to be
 displayed. This incompatibility was caused by adding OS/2 version 1.20
 filename support to UNDEL.EXE and EXP.EXE.

 As a workaround, rename the C 5.10 UNDEL.EXE to UNDEL51.EXE and the C
 6.00 UNDEL.EXE to UNDEL60.EXE.


 163. Invalid Switch and Extensions in Brief Emulation

 Product Version(s): 1.02   | 1.02
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified:  6-FEB-1991    ArticleIdent: Q67762

 The M editor version 1.02 comes with a BRIEF.INI file, which contains
 the key settings for Brief emulation. If you want Brief emulation, you
 must rename this file to "TOOLS.INI". This file will generate the
 following three messages when M loads the TOOLS.INI file during
 initialization:

    mhctx is not an editor switch
    load:$PATH:ulcase - no such file or directory
    load:$PATH:justify - no such file or directory

 The messages are caused by the following three lines:

    Line 223: "mhctx:Alt+H"
    Line 263: "load:$PATH:ulcase"
    Line 369: "load:$PATH:justify"

 Deleting these three lines will not change the performance of the M
 editor, and will eliminate the messages they cause when M is
 initialized.






 Microsoft NMake [Make Utility]
 =============================================================================


 1. NMAKE and the Backslash "\" Character

 Product Version(s): 1.00   | 1.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified:  3-MAY-1989    ArticleIdent: Q43064

 The backslash "\" character in NMAKE has two different meanings
 depending on how it is used. One of its uses is as a line-continuation
 character. The other use is as a path specifier.

 The primary use of "\" is as a line continuation-character. For
 example, if you have a dependency line that extends more than one
 line, use the "\" character to continue to the next line. It is
 correct to include a space prior to the "\" or to append it to the
 last dependent, as in the following examples:

 FOO : obj1 obj2 obj3 obj4 obj5 \  (CORRECT)
 obj6 obj7...etc.

 FOO : obj1 obj2 obj3 obj4 obj5\   (CORRECT)
 obj6 obj7...etc.

 The "\" character is also used as a path specifier. When "\" is the
 last character on the line and is meant as a path specifier, you must
 precede it with the caret "^" character to tell NMAKE to override its
 meaning as a line-continuation character.

 The following macro definition is an example demonstrating the use of
 "\" as a path specifier:

 exe_dir = c:\bin^\    (CORRECT)

 exe_dir = c:\bin\     (INCORRECT)

 The following will be interpreted as a line-continuation character.

 exe_dir = c:\bin\     (INCORRECT)

 Preceding the "\" with another "\" will nullify the meaning as a
 line-continuation character. However, when this macro is expanded,
 both backslashes will appear, producing an incorrect path.


 2. NMAKE Is Case Sensitive

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified:  3-MAY-1989    ArticleIdent: Q43999

 It is not clearly stated in the manual that NMAKE IS case sensitive.
 Case sensitivity is imposed on the following:

 1. Macros

    For instance, if you define "TEXT" as a macro, you must use $(TEXT)
    to insert it. If $(text) is used, the macro is undefined and
    nothing happens.

 2. Predefined Macros (.SUFFIXES;.PRECIOUS, CC, etc.)

    Predefined macros such as .SUFFIXES must be in all in uppercase
    letters. If you use .suffixes, NMAKE returns the error ".suffixes
    too long: truncated to 8.3".

 3. File extensions

    When adding file extensions to the .SUFFIXES list, you must
    preserve case. For example, to add the file extension .dll to the
    suffix list, you would put the following line in your makefile:

       .SUFFIXES : .dll

    Then, all files with the .dll extension must have the .dll
    extension in lowercase letters.


 3. NMAKE Uses "makefile " Ignoring File Name on Command Line

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | S_QuickC
 Last Modified: 10-NOV-1989    ArticleIdent: Q44777

 When using NMAKE, you normally put the makefile's name on the command
 line as follows:

    NMAKE test.mak

 Although this works correctly for most cases, if there is a file named
 "makefile." in the current working directory, NMAKE uses that file
 instead of the one specified on the command line.

 To be sure NMAKE uses the makefile specified on the command line, you
 must have a /F switch before the makefile name as follows:

    NMAKE /F test.mak

 This is expected behavior, as documented on Page 156 of the "Microsoft
 QuickC ToolKit" manual for QuickC Version 2.00.


 4. Modifications for an Existing Make File Used with MAKE

 Product Version(s): 1.00   | 1.10
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | s_quickc  s_c  h_FORTRAN
 Last Modified: 16-JAN-1990    ArticleIdent: Q44130

 Question:

 What modifications need to be made to an existing make file that was
 used with MAKE, and why?

 Response:

 To use NMAKE on make files originally designed for MAKE, the first
 descriptor block (target:dependent) must be a pseudotarget (see QuickC
 Version 2.00 ToolKit, Sections 7.3.5 and 7.5) that lists all of the
 original make targets in the file as the dependent files. The
 following is an example:

    ALL : test.exe test1.exe test2.exe

 The reason you must include a pseudotarget descriptor block as the
 first descriptor block in a make file is that the previous MAKE
 utility tested EACH descriptor block sequentially throughout the file.
 NMAKE, however, tests only the FIRST descriptor block unless targets
 are specifically listed on the NMAKE command line. By using a
 pseudotarget, ALL in the above example, NMAKE must now assume
 that each dependent is out of date and attempt to make it. NMAKE now
 searches the make file for each dependent file listed (test.exe,
 test1.exe, and test2.exe) to see if a descriptor block exists for it.
 This causes NMAKE to behave just like MAKE.

 Example:
 -------

    ALL : test.exe test1.obj

    test1.obj : test1.c
            cl /c test1.c

    test.exe : test.obj test1.obj
            link test test1;

 Without the pseudotarget, NMAKE tests only the first descriptor block
 and ignores any following descriptor block.


 5. How to Specify Paths in Inference Rules in NMAKE

 Product Version(s): 1.00   | 1.10
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | s_quickc  s_c  h_FORTRAN
 Last Modified: 23-MAR-1990    ArticleIdent: Q44131

 Question:

 How to I specify paths in inference rules?

 Response:

 Note: For a complete description of this feature, see QuickC Version 2.00
 Toolkit, Section 7.3.3. One of the most powerful new features of
 NMAKE is that it allows paths to be specified in an inference rule.

 The syntax of an inference rule without paths is as follows:

    .fromext.toext:

 This syntax is somewhat limited, however, because both the "fromfile"
 and the "tofile" are evaluated as if they existed in the current
 directory. With NMAKE, a path specifier may be added to an inference
 rule by doing the following:

    {frompath}.fromext{topath}.toext:

 Note: If you use a path on one element of the inference rule, you must
 use it on both. For instance, if you want to compare any .c file in
 the current directory with its .obj file in my object directory, the
 inference rule would look like the following:

 {.}.c{c:\objects}.obj:
         cl /c $<;

 Note that the fromext (.c) has to be preceded with a path. In the case
 of the current directory, the ".", or current directory works nicely.

 When NMAKE encounters a descriptor block that has no commands
 following, it will look for an inference rule that matches the
 descriptor block. When checking for matching, NMAKE expects that the
 base name of both the target and the dependents be the same. Also, the
 paths must match exactly. In other words, the following descriptor
 line would not use the inference rule just defined because the paths
 do not match on the .obj file:

    test.obj : test.c

 In this case, the predefined inference rule for .c.obj: would be
 invoked. To invoke the inference rule just defined, the descriptor
 line would be as follows:

    c:\objects\test.obj : test.c


 6. Multiple Targets in NMAKE Do Not Work

 Product Version(s): 2.00
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist2.00 docerr S_QUICKC
 Last Modified:  2-JUN-1989    ArticleIdent: Q44757

 Multiple targets in the QuickC Version 2.00 NMAKE utility do not work
 properly. The example on the top of Page 167 of the "Microsoft QuickC
 Tool Kit" manual shows that each target listed before the dependencies
 should be evaluated; however, only the first target is evaluated, and
 the others are ignored. Make files that are simplified even more
 respond the same way.

 The following make file demonstrates the problem:

     target1.exe target2.exe: depend1.obj depend2.obj
         echo $@

 For the make file to work properly, change the file to the
 following:

     BUILD: target1.exe target2.exe

     target1.exe: depend1.obj depend2.obj
         echo $@

     target2.exe: depend1.obj depend2.obj
         echo $@

 Microsoft has confirmed this to be a problem in QuickC Version 2.00.
 We are researching this problem and will post new information as it
 becomes available.



 7. Modifying a QuickC 2.00 Make File to Run MAKE

 Product Version(s): 1.00   | 1.10
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | s_quickc  s_c  h_FORTRAN
 Last Modified: 26-MAY-1989    ArticleIdent: Q44133

 Question:

 What modifications must I make to a make file generated by QuickC
 Version 2.00 so that I can run NMAKE on it and use my Microsoft C
 Version 5.10?

 Response:

 Only a few modifications must be made to allow a make file generated
 by QuickC to invoke C Version 5.10. The following three items need to
 be changed:

 1. Change the CC macro from qcl to cl. To do this, locate the
    following line in the make file generated by QuickC and change qcl
    to cl:

       CC=qcl

 2. Take out references to ilink. The ilink references are embedded
    into your make file if you have the ilink option turned on in your
    environment. The following line in the make file

       ilink -a -e "link $(LFLAGS) @$(PROJ).crf" $(PROG)

    must be changed to the following:

       link "$(LFGLAGS) @$(PROJ).crf" $(PROG)

 3. Remove any compiler switches in the make file that cl will not
    recognize. To eliminate this problem, turn off incremental compile
    in the QuickC environment prior to making the make file.


 8. NMAKE Version 1.00 with "!" and User and Predefined Macros

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | S_QuickC buglist1.00 fixlist1.01
 Last Modified: 30-NOV-1989    ArticleIdent: Q48859

 The following NMAKE file does not produce the correct results when
 using NMAKE Version 1.00, which is supplied with the Microsoft QuickC
 compiler Version 2.00. The file replaces the user-defined macro in the
 second command line with the predefined macro in the first command
 line. The workarounds are as follows:

 1. Remove the "!" at the beginning of the first command line, which
    causes the command to be executed for each dependent file if the
    command uses one of the special macros $? or $**.

 2. Do not use a predefined macro for the first command.

 3. Do not use the predefined macro $**, a complete list of dependent
    files, for the dependent files in the first command line.

 4. Do not use a user-defined macro in the second command line.

 5. Update to the Microsoft QuickAssembler package, which is shipped
    with NMAKE Version 1.01, in which this problem is corrected.

 More information on the NMAKE utility can be found starting on Page
 155 of the "Microsoft QuickC Toolkit" manual. The following is the
 NMAKE file that fails:

 SOURCE=test.c

 test.exe: $(SOURCE)
     !$(CC) $**
     copy $(SOURCE) new

 This produces the following output:

 cl test.c
 copy cl new

 The following is the NMAKE file with the first workaround:

 SOURCE=test.c

 test.exe: $(SOURCE)
     $(CC) $**
     copy $(SOURCE) new

 This produces the following correct output:

 cl test.c
 copy test.c new

 The following is the NMAKE file with the second workaround:

 SOURCE=test.c

 test.exe: $(SOURCE)
     !cl $**
     copy $(SOURCE) new

 This also produces the correct output.

 The following is the NMAKE file with the third workaround:

 SOURCE=test.c

 test.exe: $(SOURCE)
     !$(CC) $(SOURCE)
     copy $(SOURCE) new

 This also produces the correct output.

 The following is the NMAKE file with the fourth workaround:

 SOURCE=test.c

 test.exe: $(SOURCE)
     !$(CC) $(SOURCE)
     copy test.c new
     copy $(SOURCE) new

 This produces the following output:

 cl test.c
 copy test.c new
 copy test.c new


 9. Incrementally Updating Libraries with NMAKE

 Product Version(s): 1.00 1.01 1.10 1.11 1.12 | 1.11 1.12
 Operating System:   MS-DOS                   | OS/2
 Flags: ENDUSER |
 Last Modified: 25-FEB-1991    ArticleIdent: Q48862

 The repetition modifier "!" (without the quotation marks) provided in
 NMAKE allows libraries to be maintained and incrementally updated very
 easily. By using this modifier with the special macro for dependents
 out-of-date with the target (for example, "$?"), the library update
 becomes an automated part of modifying a project.

 The following NMAKE makefile keeps FOO.LIB up-to-date based on the
 four object files listed in the OBJS macro. These object files can be
 based on C or assembly source files. The list of source-file types can
 be extended by adding the appropriate inference rules to the
 description file.

 Sample NMAKE Makefile
 ---------------------

     #
     # List of object files to be kept in library
     #
     OBJS = foo1.obj foo2.obj foo3.obj foo4.obj

     .c.obj:
         cl /c $?

     .asm.obj:
         masm $?;

     foo.lib : $(OBJS)
         !lib foo.lib -+ $?;

 The command for the library dependency line uses a predefined macro
 and a special NMAKE directive. Placing "$?" on the end of the LIB line
 expands to the list of all dependents that are out-of-date with the
 target. This list combined with "!" causes the LIB line to be executed
 once for each member in the list.

 If FOO1.OBJ and FOO3.OBJ are out-of-date with respect to FOO.LIB, "$?"
 evaluates to "FOO1.OBJ FOO3.OBJ". With "!", the following commands are
 executed:

    lib foo.lib -+ foo1.OBJ;
    lib foo.lib -+ foo3.OBJ;


 10. Explanation of Why NMAKE May Not Produce .OBJ and .EXE Files

 Product Version(s): 1.00 1.10 1.11 | 1.00 1.11
 Operating System:   MS-DOS         | OS/2
 Flags: ENDUSER |
 Last Modified: 27-OCT-1989    ArticleIdent: Q49502

 Question:

 When using the NMAKE utility, no warnings occur and the compiler
 appears to execute properly; however, the .OBJ and .EXE files are not
 created.

 If I use the MAKE utility on the same .MAK file, I get the following
 two warnings:

    warning U4000: Target does not exist.

    warning U4001: Dependent does not exist; Target not built.

 The first warning message is a standard warning that I would expect.
 Why is there a second and why aren't the .OBJ and .EXE files created?

 Response:

 Remove unexpected trailing characters from the .MAK file.

 This problem can occur because extra characters occur at the end of a
 line within the .MAK file. Common mistakes such as placing a trailing
 semicolon in the CL compile line or in the dependency line can cause
 this behavior. This applies to any unexpected characters, not just
 semicolons.

 The following example demonstrates the problem:

    file.obj: file.c <ENTER>
       CL /c /Lp file.c;  <-- Semicolon CANNOT be used with the CL command.

    file.exe: file.obj <ENTER>
       LINK file;      <-- OK, Semicolon CAN be used with the LINK command.

 Removing the semicolon at the end of the CL line eliminates the
 problem.


 11. Command Line Too Long in Makefile Can Cause Error: U1082

 Product Version(s): 1.00 1.01 1.10 1.11 1.12 | 1.11 1.12
 Operating System:   MS-DOS                   | OS/2
 Flags: ENDUSER | s_make
 Last Modified: 24-JAN-1991    ArticleIdent: Q49757

 NMAKE and MAKE require that all commands issued after a target
 dependency are less than the DOS command-line limit of 128 characters.
 If the command is too long, you may receive the following error

    U1082:  Not enough memory '...' cannot execute '...'

 where '...' is the command that was attempted. This problem most
 likely occurs with the link command line and can be easily resolved
 with a response file. Response files are documented in the utilities
 manual or the online help supplied with each compiler.


 12. Special Macros Not Recognized in NMAKE Inline Files

 Product Version(s): 1.00 1.01 | 1.00 1.01
 Operating System:   MS-DOS    | OS/2
 Flags: ENDUSER |
 Last Modified: 10-NOV-1989    ArticleIdent: Q50693

 When you use special macros to indicate targets or dependents in
 inline files, NMAKE Version 1.00 will generate the error message
 U4108, "special macro undefined." These special macros are $@, $*,
 $**, and $?.

 To prevent the problem, avoid use of these special macros in inline
 files. Instead of using those << inline files, create the response
 file in a separate NMAKE target, and redirect TYPE and ECHO commands
 to the desired file.

 $@ refers to the full name of the target, base plus extension. $*
 refers only to the base name of the target.

 $** represents the complete list of dependent files for the target. $?
 represents only the dependents that are out of date relative to the
 target.

 The following makefile will generate U4018 for $**:

 #makefile test
 FOO.EXE: *.OBJ
     LINK @<<FOO.LRF
 $**;
 <<

 To avoid the problem, break this up into two steps, the makefile and a
 linker response file with output redirected:

 #makefile test
 FOO.EXE: *.OBJ FOO.LRF
     LINK @FOO.LRF

 FOO.LRF: *.OBJ
     echo $**; >FOO.LRF


 13. Inference Rule May Fail If Blank Command Line Contains Spaces

 Product Version(s): 1.00 1.01 1.10 1.11 1.12 | 1.11 1.12
 Operating System:   MS-DOS                   | OS/2
 Flags: ENDUSER |
 Last Modified: 24-JAN-1991    ArticleIdent: Q50383

 When using inference rules in an NMAKE description file, the target/
 dependency line must be followed by a blank line (no space
 characters); otherwise, the inference rule commands will not be
 executed. NMAKE checks this line for any ASCII characters; if ANY
 characters exist, NMAKE will ignore the inference rule and try to
 execute the line, even if it contains only a space or spaces.

 The following is a simple example, which demonstrates this problem:

 .c.exe:
   cl $**

 ALL : main.exe

 main.exe : main.c
 <space>

 Nothing happens if this description file is passed to NMAKE because
 the space character will cause NMAKE to assume there are explicit
 commands following the target/dependency line, causing it to ignore
 the inference rule. Note that this is expected behavior for NMAKE.

 MAKE version 4.x inference rules/description blocks do not exhibit
 this behavior. This is something to keep in mind when converting
 description files from MAKE to NMAKE.


 14. Using "." for Path in Inference Rules Causes U1073

 Product Version(s): 1.00 1.01 | 1.01
 Operating System:   MS-DOS    | OS/2
 Flags: ENDUSER | buglist1.01
 Last Modified: 18-DEC-1989    ArticleIdent: Q51723

 NMAKE does not accept a dot (.) to identify the current directory in
 inference rule paths. When specifying paths for each of the
 extensions, using the following form

    {frompath}.fromextension{topath}.toextension

 and using "{.}" (without the quotation marks) to indicate the current
 directory for the "topath", causes the following error:

    NMAKE : fatal error U1073: don't know how to make 'filename.ext'

 To work around this, the current directory for topath must be
 specified with "{}". However, both notations are acceptable when
 specifying the "frompath".

 The following makefile causes the error:

 .SUFFIXES: .h .c .obj .exe

 #macros
 a=tools.h
 jbo=grdemo.obj turtle.obj menu.obj
 cc=qcl -c

 #inference rules
 {d:\qc2\work}.c{.}.obj:          #*** the '{.}' must be '{}' ***
  $(cc) $<

 {}.obj{d:\qc2\lib}.exe:
  link $(**R),,, graphics.lib;

 #target-dependencies
 run: d:\qc2\lib\grdemo.exe

 d:\qc2\lib\*.obj: d:\qc2\work\*.c

 d:\qc2\lib\grdemo.exe: $(jbo)


 15. Redirecting NMAKE 1.00/1.01 Output with -p Gives False Errors

 Product Version(s): 1.00 1.01
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist1.00 buglist1.01 fixlist 1.11
 Last Modified: 24-JAN-1991    ArticleIdent: Q57500

 Redirecting the output of NMAKE version 1.00 or 1.01 can cause
 inference rules to fail if all of the following conditions are met:

 1. The inference rules are in uppercase letters.
 2. The -p option is used.
 3. The output is redirected.

 This problem is somewhat obscure, and it can be frustrating if you
 unwittingly meet all of these conditions. The error message displayed
 depends on the inference rule used, but it resembles the following:

    NMAKE : warning U4017: ignoring rule .C.OBJ (extension not in
            .SUFFIXES)

 The above error message is displayed with the following description
 file initiated with the command "NMAKE -p > out.txt":

 Description File
 ----------------

 # start

 .C.OBJ:
   cl $*

 main.obj : main.c

 # end

 Microsoft has confirmed this to be a problem in NMAKE versions 1.00
 and 1.01. This problem was corrected in NMAKE version 1.11.


 16. Missing Right Parenthesis in Sample NMAKE File Hangs Machine

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | h_fortran s_quickc s_quickasm buglist1.00
 Last Modified: 15-MAR-1990    ArticleIdent: Q59069

 If you forget the right parenthesis in an IF "$(flag)"=="comparison"
 line in a makefile and run the makefile through NMAKE, you can receive
 machine hangs or corrupt COMMAND.COM messages under DOS or an Internal
 Processing Error under OS/2.

 Microsoft has confirmed this to be a problem with Version 1.00. We are
 researching this problem and will post new information here as it
 becomes available.

 The following makefile, simplified from the sample makefile on Page
 172 of the "QuickC ToolKit" manual, demonstrates this problem:

 debug=Y
 CC=qcl
 !CMDSWITCHES +D
 HELLO.EXE : HELLO.OBJ
 !IFDEF debug
 !   IF "$(debug"=="y"
                 LINK /CO hello;
 !   ELSE
                 LINK hello;
 !   ENDIF
 !ELSE
 !   ERROR Macro named debug is not defined.
 !ENDIF

 Adding a right parenthesis after "$(debug solves the problem.

 The error seems to occur because NMAKE does not recognize the end of
 the line and continues to parse the line until the end of the file. A
 customer has reported receiving "U1076, Line too long" messages,
 followed by a DOS level error reading "Invalid COMMAND.COM - system
 halted."

 Testing the same problem under an OS/2 1.20 DOS Box returned Internal
 Processing Errors and halted the system with no other error messages.


 17. NMAKE 1.01 Does Not Properly Expand Wildcard Arguments

 Product Version(s): 1.01   | 1.01
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified: 15-MAY-1990    ArticleIdent: Q59254

 NMAKE version 1.01 doesn't properly expand wildcard command-line arguments.
 For example, if we were to have a makefile that looked similar to the
 following

 a.exe : a.c
     echo cl a.c

 b.exe : b.c
     echo cl b.c

 And we were to say:

 NMAKE *.exe /A

 NMAKE wouldn't properly expand "*.exe" to equate to both a.exe and
 b.exe; it would merely build only the first target in the list.

 NMAKE versions 1.00 and 1.10 do not exhibit this behavior.


 18. NMAKE /D /C Switches Suppress Modification Date

 Product Version(s): 1.00 1.01 1.10 1.11
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist1.00 buglist1.01 buglist1.10 buglist1.11
 Last Modified: 18-NOV-1990    ArticleIdent: Q59384

 When using the NMAKE /D and /C switches together, the modification
 date of each file will not be displayed when the date is checked. A
 short description of each switch is described as follows:

    /D  Displays the modification date of each file when the date is
        checked.

    /C  Suppresses the NMAKE copyright message and prevents nonfatal
        error or warning messages from being displayed.

 Microsoft has confirmed this to be a problem with NMAKE Versions 1.00,
 1.01, and 1.10. We are researching this problem and will post new
 information here as it becomes available.


 19. Trouble with Filenames Containing a Dollar Sign ($)

 Product Version(s): 1.01    | 1.01
 Operating System:   MS-DOS  | OS/2
 Flags: ENDUSER | buglist1.01
 Last Modified: 14-MAR-1990    ArticleIdent: Q59409

 If you use a filename that contains a dollar sign ($) in a NMAKE
 description file, you can use the escape character (^) to tell NMAKE
 that the dollar sign is part of your filename, not a macro character.
 However, using the escape character within an inline response file
 does not work and you must use the double dollar sign ($$).

 Consider the following NMAKE description file:

     all:test^$.exe;

     test^$.obj: test^$.c
        cl /c test^$.c

     test^$.exe: test^$.obj
        link @<<
              test^$.obj,
              test^$.exe,
              NUL,;
     <<

 In this file, the escape character (^) is used to tell NMAKE that the
 $ is part of the filename TEST$.* and is not denoting the use of a
 macro. When TEST$.C is compiled, everything works correctly until you
 get to the inline response file for LINK. NMAKE does not interpret the
 ^ character, but instead passes it on to LINK.EXE. LINK then tries to
 link TEST^$.OBJ instead of TEST$.OBJ and fails. If you eliminate the ^
 to pass TEST$.OBJ to link, NMAKE fails with an error about an invalid
 macro.

 NMAKE is in error here. NMAKE should do one of two things when parsing
 the inline response file.

 1. NMAKE should interpret the ^ to leave the $ as part of the filename.

 2. NMAKE should ignore the $ so that you can just list TEST$.OBJ
    because it doesn't make sense to have macros in external response
    files when parsing an inline response file.

 Microsoft has confirmed this to be a problem with NMAKE Version 1.01.
 We are researching this problem and will post new information here as
 it becomes available.

 The following are two suggested workarounds:

 1. Use an external response file. Then your link line would appear
    similar to link @FILE.RES and you could put TEST$.OBJ directly in
    the response file.

 2. Use $$ as the escape sequence instead of ^$ in the inline response
    file. For example, change

       link @<<
           test^$.obj,
           test^$.exe,
           NUL,;
       <<

    to the following

       link @<<
           test$$.obj,
           test$$.exe,
           NUL,;
       <<

    and NMAKE will correctly pass TEST$.OBJ to the linker.


 20. In What Order Does NMAKE Build Files?

 Product Version(s): 1.00   | 1.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified: 15-MAY-1990    ArticleIdent: Q59420

 Question:

 I need to have my source files built in a particular order but I can't
 get NMAKE to build them that way. NMAKE seems to build the source
 files in the order it wants. What is the order in which NMAKE builds
 files?

 It is definitely possible to specify the order in which NMAKE builds
 your files.

 The first thing NMAKE does is check the command line. You can specify
 the targets in the order you want them built and NMAKE will build them
 in that order. If NMAKE doesn't find any targets on the command line,
 it builds the first target in the description file.

 NMAKE will build all of the dependents in the order in which they are
 specified on the first target line. For most description files, the
 first target in the file is the ALL:FILENAME.EXE pseudotarget. In this
 case, NMAKE will build FILENAME.EXE, and then the order depends on the
 dependency for FILENAME.EXE.

 This can be more clearly explained in the following examples:

 Example 1
 ---------

 Consider the following description file:

             all:three.obj two.obj one.obj main.exe

             one.obj:one.c
                 cl /c one.c

             two.obj:two.c
                 cl /c two.c

             three.obj:three.c
                 cl /c three.c

             main.exe:three.obj one.obj two.obj
                 link one two three, main;

 In this example, the files are compiled in the order: THREE.C, TWO.C,
 ONE.C. After those three files are compiled, the link for MAIN.EXE is
 executed. They are executed in that order because that is the explicit
 order given in the first target in the file and NMAKE builds the first
 target in the file when nothing is specified on the command line.

 Example 2
 ---------

 Now, consider the following description file that has been slightly
 modified from the one shown in Example 1 above:

             all:main.exe

             one.obj:one.c
                 cl /c one.c

             two.obj:two.c
                 cl /c two.c

             three.obj:three.c
                 cl /c three.c

             main.exe:three.obj one.obj two.obj
                 link one two three, main;

 In this example the files are compiled in the order: THREE.C, ONE.C,
 TWO.C. After that, the link statement will then be executed because
 there is nothing specified on the command line, so NMAKE will build
 the first target in the file, which is MAIN.EXE. When NMAKE looks at
 what it needs to build MAIN.EXE, it sees the list of dependents and
 builds them in that order.

 In summary, NMAKE looks first on the command line. If nothing is found
 there, it builds the first target in the description file by building
 each of its dependents in the order specified. If the dependent of the
 first target specifies another target, the dependents of that target
 are built in the order they are specified and so on.


 21. Multiple Dependency Blocks Are Not Cumulative

 Product Version(s): 1.00 1.01 1.10 1.11 | 1.01 1.10 1.11
 Operating System:   MS-DOS              | OS/2
 Flags: ENDUSER |
 Last Modified: 16-OCT-1990    ArticleIdent: Q59526

 Question:

 Specifying a target in multiple dependency blocks seems to confuse
 NMAKE. If my make file says something similar to the following

 FOO.EXE:: FOO1.obj
 FOO.EXE:: FOO2.obj
 FOO.EXE:: FOO3.obj
   link foo.exe

 FOO.EXE:: FOO.RES
   RC FOO.RES FOO.EXE

 and FOO1.OBJ and FOO2.OBJ are newer than FOO.EXE but FOO3.OBJ is not,
 FOO.EXE will not be built. To further confuse the issue, the following
 is the output from running NMAKE with the /d (display file dates)
 option:

 C:\>NMAKE /d foo.mak

   foo.exe                    Wed Mar 07 08:42:38 1990
     foo1.obj                 Thu Mar 08 15:25:44 1990
 ** foo1.obj newer than foo.exe
     foo2.obj                 Wed Mar 08 08:38:56 1990
 ** foo2.obj newer than foo.exe
     foo3.obj                 Thu Mar 01 09:49:52 1990
     foo.res                  Thu Mar 01 09:49:52 1990
 'foo.exe' is up-to-date.

 Obviously, NMAKE realizes the foo1 and foo2 .OBJs are newer, but
 FOO.EXE is never linked. Why not?

 Response:

 The multiple dependency construct, indicated by a double colon (::)
 following the target, is very useful in NMAKE because it allows the
 programmer to specify what operations are to take place on a target
 based on various dependents. For instance, in PM (Presentation
 Manager) programming the MAKE file can indicate that if the .OBJs
 change, execute the linker to rebuild the application. On the other
 hand, if all that changes is the resource file, only the resource
 compiler needs to be executed.

 However, there is a limitation to this feature. The command block for
 a target-dependency group MUST immediately follow it. They are not
 cumulative like normal dependency blocks. Therefore, one workaround to
 the above example is the following:

 FOO.EXE:: FOO1.obj
   link foo.exe

 FOO.EXE:: FOO2.obj
   link foo.exe

 FOO.EXE:: FOO3.obj
   link foo.exe

 FOO.EXE:: FOO.RES
   RC FOO.RES FOO.EXE

 The second alternative is to put all the dependencies on the same
 line as the target, for example:

 FOO.EXE:: FOO1.obj FOO2.obj FOO3.obj
   link foo.exe

 FOO.EXE:: FOO.RES
   RC FOO.RES FOO.EXE


 22. A Complete Example of Utilizing Paths in NMAKE

 Product Version(s): 1.00 1.01 1.11
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 18-APR-1990    ArticleIdent: Q60340

 The make file shown below is an NMAKE example of using paths in
 macros, inference rules, and target dependencies (descriptor blocks).
 This is a working example of what is described on Page 298 of the
 "Microsoft FORTRAN CodeView and Utilities User's Guide" and Page 168
 of the "Microsoft QuickC Tool Kit."

 This make file compares the modification dates of the .H and the .C
 files with the .OBJ files, and the .OBJ files with the .EXE files. If
 any of the dependent files have changed more recently than the target
 files, the specified series of commands is executed. The .H and the
 .C files in the work directory are compared to the .OBJ files of the
 lib directory.

 If any of the source file(s) have changed since the last .OBJ was
 .created, then it is recompiled and copied from the current
 directory to the lib directory. The .OBJ files in the lib directory
 are compared to the .EXE files in the current directory. If any of the
 .OBJ files have changed since the last .EXE was created, then the
 .OBJs are relinked.

 Sample Make File
 ----------------

 #macros

 objdir =d:\qc2\lib
 wrkdir =d:\qc2\work
 list   =$(objdir)\grdemo.obj $(objdir)\turtle.obj \
 $(objdir)\menu.obj
 cc     =qcl -c

 #inference rules

 #compile
 {$(wrkdir)}.c{$(objdir)}.obj:
  $(cc) $<
  copy $(*F).obj $(*R).obj
  erase $(*F).obj

 #link
 {$(objdir)}.obj{}.exe:
  link $(**R);

 #target-dependencies

 run: grdemo.exe

 $(objdir)\*.obj: $(wrkdir)\$$(@B).c $(wrkdir)\menu.h \
 $(wrkdir)\turtle.h

 grdemo.exe: $(list)


 23. NMAKE May Invoke MASM Instead of the C Compiler

 Product Version(s): 1.00 1.01 1.11 | 1.01 1.11
 Operating System:   MS-DOS         | OS/2
 Flags: ENDUSER | docsup s_pwb h_fortran
 Last Modified: 17-JUL-1990    ArticleIdent: Q60746

 When using an NMAKE file in combination with adding /Fa to the
 compiler options within Programmer's WorkBench (PWB), NMAKE will
 invoke the Macro Assembler, if it is in the current search path.

 This does not occur the first time you build your application, but it
 does occur the second time, and thereafter, because of the generation
 of the .ASM created by the compiler.

 Files with the .ASM extension have a predefined inference rule within
 NMAKE to invoke MASM. However, the inference rule for .ASM files takes
 place before the rule for files with the .C or .OBJ extension.
 Therefore, if you have a filename with the same base name, but one has
 an .ASM extension and the other has a .C extension (as is the case
 with the /FA switch), the .ASM file will be assembled before the .C
 file will be compiled. Since the assembly step generates an .OBJ file
 that is newer than the .C file, the .C file is never compiled.

 Use the following procedures to work around this behavior:

 1. The best workaround is to use /Fa [LSTFILE.EXT] with a filename
    included as a compiler option, instead of allowing the /Fa option
    to default to its <filename>.ASM.

    Example: /Fa <filename>.ASC

    In using this method, the .C file will be compiled, instead of the
    .ASM version being assembled.

 2. Use the /Fc compiler option in place of the /Fa option (if you just
    want to look at an assembly source listing). This produces a .COD
    file (combined assembly and C source listing).

 3. Use the /R switch for the NMAKE invocation to ignore inference
    rules and macros that are predefined or defined in the TOOLS.INI
    file.

 For a more in-depth discussion on the /R switch and its effects, see
 the following references:

 1. The "Microsoft C Advanced Programming Techniques" reference manual

    Page(s) 112-114 Predefined macros
            118-119 Predefined inference rules
            125     /R Switch

 2. The "Microsoft FORTRAN, CodeView and Utilities User's Guide"

    Page(s) 288     /R Switch
            295-297 Predefined macros
            299-230 Predefined inference rules

 3. The "Microsoft QuickC Toolkit" reference manual

    Page(s) 158     /R Switch
            165-197 Predefined macros
            169     Predefined inference rules


 24. Looking for Files in Different Directories

 Product Version(s): 1.00 1.01 1.10 1.11 | 1.01 1.10 1.11
 Operating System:   MS-DOS              | OS/2
 Flags: ENDUSER | s_c s_quickc s_quickasm h_fortran
 Last Modified: 17-JUL-1990    ArticleIdent: Q60867

 If you use the "directory search" feature of NMAKE (curly braces "{}")
 to use a separate directory for some files, the location of these
 files cannot be inferred in subsequent dependency rules.

 The following code example demonstrates this confusion:

    test.exe: {\obj}test.obj
       link \obj\test.obj graphics.lib;

    test.obj: test.c test.h
       cl /c /Fo\obj\test.obj test.c

 If TEST.EXE and \OBJ\TEST.OBJ were up to date and we were to change
 one of the dependencies for TEST.OBJ, nothing would happen. This is
 because \OBJ\TEST.OBJ doesn't have any dependencies. The TEST.OBJ
 dependency line is only for the current directory. If we were to
 change the TEST.OBJ line to the following

    {\obj}test.obj: test.c test.h

 a change to TEST.C or TEST.H would cause \OBJ\TEST.OBJ and TEST.EXE
 to be updated.

 Note: NMAKE has a predefined inference rule for C.EXE that causes
 TEST.EXE to be relinked in the above example if it is out of date with
 TEST.C.


 25. /MAKE Option Is Invalid with NMAKE

 Product Version(s): 1.11   | 1.11
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | docerr
 Last Modified: 25-MAY-1990    ArticleIdent: Q61619

 On Page 43 of the "Microsoft C Reference" manual for version 6.00,
 NMAKE is described as being upwardly compatible with the earlier MAKE
 utility through the use of the /MAKE option. Since NMAKE does not
 support the /MAKE option, it produces the error "U1065:  Invalid
 option 'm'."

 To work around this problem, you can either use the earlier MAKE
 utility, or use a pseudo-target on the first line of your make file.
 The pseudo-target line should read as follows:

    ALL: [target name.exe/obj]

 For more information about the differences between MAKE and NMAKE, see
 Section 6.9 of the "Microsoft C Advanced Programming Techniques"
 manual for version 6.00.


 26. Using "!" and "$?" Do Not Work as Expected with NMAKE 1.11

 Product Version(s): 1.11   | 1.11
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | buglist1.11
 Last Modified:  6-FEB-1991    ArticleIdent: Q61808

 Applying the "!" (exclamation point) operator to the beginning of a
 command line using the macro "$?" should cause the command to be
 executed once for every out-of-date dependent file. (This is
 documented on Page 108 of the "Advanced Programming Techniques" manual
 included with the Microsoft C Optimizing Compiler version 6.00.)

 This feature works correctly in NMAKE version 1.00, but does not work
 as expected in version 1.11. NMAKE version 1.11 is included with the
 Microsoft C Compiler version 6.00.

 In version 1.11 of NMAKE, the $? macro evaluates to the list of every
 dependent, regardless of whether it is out of date or not. This is not
 the correct behavior.

 To re-create this problem, save the following lines to a file called
 MAKEFILE:

    new.lib: a.obj b.obj c.obj
        !lib $@-+$?;

 Assuming that only a.obj is out-of-date with respect to new.lib, the
 following will be produced upon running NMAKE:

 1. NMAKE 1.00:

       lib new.lib-+a.obj;

 2. NMAKE 1.11:

       lib new.lib-+a.obj
       lib new.lib-+b.obj
       lib new.lib-+c.obj

 Example 1 above shows the correct function of the $? macro.

 Fortunately, the problem above is easy to fix.  NMAKE performs
 correctly if two colons (::) are placed after the target new.lib on
 the dependency line.  The NMAKE file has been re-written below so that
 the $? macro will work with NMAKE 1.11.

 MODIFIED NMAKE FILE
 -------------------
 new.lib::a.obj b.obj c.obj
    !lib $@-+$?;

 The use of the two colons on the dependency line is described on page
 109 of the Advanced Programming Techniques manual included with the
 Microsoft C compiler version 6.00.

 Microsoft has confirmed this to be a problem with NMAKE version 1.11.
 The problem has been resolved with later versions of NMAKE.


 27. NMAKE U1001 Illegal Character Caused by Corrupted MAKEDIR

 Product Version(s): 1.11
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist1.11
 Last Modified:  4-DEC-1990    ArticleIdent: Q61978

 NMAKE version 1.11 may produce a U1001 "syntax error: illegal
 character <character> in macro" while building a project.

 NMAKE has an internal macro, MAKEDIR, which contains the full drive
 and path to the directory from where NMAKE was invoked. This macro is
 corrupted in NMAKE version 1.11 under DOS. Rather than the correct
 pathname, the macro contains "garbage" or graphics characters. This
 macro can cause the U1001 "illegal character" error message.

 To display the contents of MAKEDIR, invoke NMAKE with the /P switch.
 This switch causes all macros to be displayed to the screen. To work
 around this problem, manually set MAKEDIR in the .MAK file for the
 project. Set it to the drive and path where the project is being
 built. If MAKEDIR is manually set in the .MAK file, it will override
 the default setting and correct the problem.

 Microsoft has confirmed this to be a problem with NMAKE version 1.11.
 We are researching this problem and will post new information here as
 it becomes available.

 NMAKE version 1.11 comes with Microsoft C Professional Development
 System version 6.00 for MS-DOS and MS OS/2.

 This problem does not occur with NMAKE version 1.10. The problem
 occurs only with the DOS version of NMAKE, not the protected mode
 version of NMAKE version 1.11.


 28. Can't Use Multiple Description Blocks with NMAKE Version 1.10

 Product Version(s): 1.10
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist1.10 fixlist1.11 b_basiccom
 Last Modified: 25-JUL-1990    ArticleIdent: Q62332

 Page 639 of "Microsoft BASIC 7.0: Programmer's Guide" explains how you
 can use NMAKE to specify more than one description block for the same
 target.

 The example given on this page is the proper way to specify more than
 one description block; however, this feature does not function
 correctly in NMAKE version 1.10. It does function correctly in NMAKE
 version 1.11.

 NMAKE version 1.10 shipped with the Professional Development System
 (PDS) BASIC version 7.00. NMAKE version 1.11 shipped with Microsoft C
 Professional Development System (PDS) version 6.00.

 The following example specifies more than one description block for
 the same target by using two colons (::) as the separator instead of
 one. The following example is taken from Page 639 of "Microsoft BASIC
 7.0: Programmer's Guide":

       TARGET.LIB :: A.ASM B.ASM C.ASM
          MASM A.ASM B.ASM C.ASM;
          LIB TARGET -+A.OBJ -+B.OBJ -+C.OBJ;
       TARGET.LIB :: D.BAS E.BAS
          BC D.BAS;
          BC E.BAS;
          LINK D.OBJ E.OBJ;
          LIB TARGET -+D.OBJ -+E.OBJ;

 Given the two description blocks above, NMAKE should update the
 library named TARGET.LIB. In the first description block, if any of
 the assembly language files have changed more recently than the
 library, the assembly files will be assembled and the library will be
 updated with the new .OBJs. In the second description block, the BASIC
 files that have changed should be compiled and the library should also
 be updated with the new OBJs.

 When using NMAKE version 1.10, the commands in the first description
 block are executed correctly; however, the commands in the second
 description block are never executed.

 Microsoft has confirmed this to be a problem in NMAKE version 1.10.
 This problem was corrected in version 1.11.


 29. Expression in Brackets "

 Product Version(s): 1.00 1.01 1.10 1.11 | 1.01 1.10 1.11
 Operating System:   MS-DOS              | OS/2
 Flags: ENDUSER |
 Last Modified: 27-JUN-1990    ArticleIdent: Q63146

 When using the !IF directive in conjunction with the square brackets
 "[]" in the NMAKE utility, all expressions inside square brackets will
 be evaluated when NMAKE initially reads the makefile, before any
 commands are executed (and before dependency blocks are evaluated).

 The square brackets are used within NMAKE to denote program
 invocations in expressions within an !IF directive, as documented in
 Section 6.3.5, Pages 120-121 of the "Advanced Programming Techniques"
 manual shipped with the Microsoft C compiler version 6.00.

 By design, all the program invocations are executed when NMAKE starts
 up, regardless of whether or not they are contained in a dependency
 block. The return values of these program invocations can then be used
 within the !IF expression to evaluate the expression.

 The following makefile displays this behavior:

    test.exe: test.c
    !IF ( [check /f] < 3 )
       cl test.c
    !ENDIF

 In this example, the program "check /f" will be executed each time the
 makefile is called, regardless of whether or not the file TEST.EXE is
 up to date.


 30. Changing Directories in Make Files Not Supported by NMK.COM

 Product Version(s): 1.11
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist1.11 S_QUICKC S_C
 Last Modified: 31-AUG-1990    ArticleIdent: Q64028

 Using a command to change directories in a make file will cause
 unexpected results with NMK.COM version 1.11. This is a side effect of
 a problem with NMAKE.EXE where directory changes within make files are
 executed while processing the make file, and the current directory is
 not reset upon exit.

 NMK spawns NMAKE to do its processing. While NMAKE is processing, if
 it sees a change drive/directory command, it must make the change to
 finish processing the make file. The problem is that it doesn't reset
 the drive when it is through processing. This causes NMK, when control
 is returned to it, to spawn the actual commands from the final
 drive/directory, rather than where it was originally invoked.

 The make file below, if run from Drive D, will demonstrate the
 problem. It works properly with NMAKE.EXE but not with NMK.COM.

 all: cded.exe

 cded.exe: cded.obj
   c:\
   copy cded.obj cded.exe

 cded.obj: cded.mak
   copy cded.mak c:\cded.obj

 To work around the problem, add a line at the end of each place block
 where you change the drive/directory to the original one (if known).
 For example, change the above make file to the following:

 all: cded.exe

 cded.exe: cded.obj
   c:\
   copy cded.obj cded.exe
   d:

 cded.obj: cded.mak
   copy cded.mak c:\cded.obj


 31. Spaces in Inference Rules Corrupt NMAKE Macro Expansion

 Product Version(s): 1.00 1.11 | 1.00 1.11
 Operating System:   MS-DOS    | OS/2
 Flags: ENDUSER | s_quickc
 Last Modified: 28-AUG-1990    ArticleIdent: Q65084

 If a space is inserted between the target and dependent extensions in
 an inference rule, it will cause NMAKE's default macros to expand
 incorrectly. The correct syntax for inference rules is to list the
 dependent file extension followed by the target file extension WITHOUT
 any embedded spaces.

 The following sample make files demonstrate a few of the problematic
 results that are possible if spaces are used in an inference rule. In
 both cases below, note that it is the embedded spaces that cause NMAKE
 to invoke the commands incorrectly. Removing the spaces allows NMAKE
 to generate the desired commands.

 Example 1
 ---------

 {c:\source\}.c {c:\objs\}.obj:
   cl $*

 ALL: c:\objs\foo2.obj

 c:\objs\foo2.obj: c:\source\foo2.c

 Command executed by NMAKE:

 cl {c:\objs\}

 Example 2
 ---------

 .c .obj:
   cl $<

 ALL: foo.obj

 foo.obj: foo.c

 Command executed by NMAKE:

 cl


 32. In-line File in Inference Rule Causes Bad Macro Substitution

 Product Version(s): 1.11   | 1.11
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | buglist1.11
 Last Modified: 11-NOV-1990    ArticleIdent: Q66459

 Using an in-line file inside of an inference rule can cause improper
 results in macro substitutions following the in-line file. The example
 below demonstrates the problem.

 Make File Example
 -----------------

 EXENAME=test.exe
 SAMPLEDIR=\test

 .obj.exe:
   link @<<lrf     <--- In-line file with $(EXENAME) macro
 $<                     causes the problem.
 $(EXENAME);
 <<KEEP
   cd $(SAMPLEDIR)

 test.exe:test.obj

 test.obj:test.c

 The above NMAKE description file produces the following output:

    cl -c test.c
    link @lrf
    cd test.exe    <---- This is wrong.  It should be "cd \test"
 NMAKE: fatal error U1077: 'cd' return code 1
 Stop.

 The third line of the output is incorrect. The macro $(SAMPLEDIR) is
 replaced with the value of $(EXENAME).

 Microsoft has confirmed this to be a problem in version 1.11. We are
 researching this problem and will post new information here as it
 becomes available.


 33. Documentation Error: Extmake Syntax for %|partsF Incorrect

 Product Version(s): 1.11   | 1.11
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | docerr
 Last Modified:  6-NOV-1990    ArticleIdent: Q66474

 The extmake syntax for determining the complete name of the first
 dependent in a NMAKE description file is incorrectly described in the
 "Advanced Programming Techniques" manual on Page 124.

 The extmake syntax described on Page 124 of the "Advanced Programming
 Techniques" manual lists the syntax as

    %|partsF

 where parts is one or more of the following:

    Letter            Description
    ------            -----------

    d                 Drive
    e                 File extension
    f                 File base name
    p                 Path
    s                 Complete name

 However, "s" is not a valid selection. You may use %s, or you may use
 %|partsF, where "parts" is one or more of the above (d, e, f, or p,
 but not s). The following makefile illustrates the problem.

 Sample Makefile
 ---------------

    sample.obj: sample.c
         cl /c %|sF

 If this makefile is run, it will produce the following error message:

    NMAKE : fatal error U1098: extmake syntax in sF incorrect

 The online help specifies the correct syntax for using the extmake
 switch:

    Letter     File-Specification Part
    ------     -----------------------

    p          Path
    d          Drive
    f          Base name
    e          Extension

 The makefile below shows the correct extmake syntax for obtaining the
 complete name of the first dependent:

 Correct Makefile
 ----------------

    sample.obj: sample.c
         cl /c %s


 34. Problem in NMAKE 1.11 with Multiple Dependency Blocks

 Product Version(s): 1.11   | 1.11
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | buglist1.11 fixlist1.12 s_c
 Last Modified:  9-NOV-1990    ArticleIdent: Q66571

 The sample makefile below will be correctly executed in all cases
 except if the target is missing. In that case, both sets of commands
 will be executed even though the second set is not necessary.

 Microsoft has confirmed this to be a problem in NMAKE version 1.11.
 This problem has been corrected in version 1.12, which shipped with
 Microsoft COBOL version 4.00.

 Multiple Dependency blocks are supposed to be evaluated one at a time.
 In the sample makefile, because the target is missing when NMAKE is
 invoked, it assumes that both sets of commands will need to be
 invoked. This is incorrect behavior.

 Sample Makefile
 ---------------

 test.exe :: test.obj test.def
     link /nod test,,,slibcew libw, test.def
     rc test.res

 test.exe :: test.res
     rc test.res


 35. NMAKE 1.11 Fails to Stop If Command Is Redirected

 Product Version(s): 1.11
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist1.11 fixlist1.12
 Last Modified:  9-NOV-1990    ArticleIdent: Q66572

 If the command line that NMAKE invokes is redirected to another
 output file and the command returns a non-zero return code, NMAKE
 version 1.11 will not stop the build process.

 Microsoft has confirmed this to be a problem in the DOS version of
 NMAKE.EXE. This problem has been corrected in version 1.12.

 The following is a sample make file that, with NMAKE version 1.11,
 will fail to stop if the compiler returns an error; with version 1.12,
 it correctly stops the build process:

 all: foo.exe

 foo.obj: foo.c
    cl /c /AS foo.c >foo.err

 foo.exe: foo.obj
    link /NOI /NOE foo.obj;

 The easiest way to workaround this is to redirect from the command
 line, for example:

    nmake /f foo.mak >foo.err

 The drawback to this is that you can only have one error log.


 36. NMAKE /N Doesn't Work Across Multiple Dependency Blocks

 Product Version(s): 1.11 1.12 | 1.11 1.12
 Operating System:   MS-DOS    | OS/2
 Flags: ENDUSER | buglist1.11 buglist1.12
 Last Modified:  7-NOV-1990    ArticleIdent: Q66644

 Given the sample makefile below and the fact that mod2.c has been
 changed, invoking NMAKE /N displays the following commands:

    cl /c -c mod2.c
    lib sub.lib -+ mod2.obj;

 However, if NMAKE is run without the /N parameter, the following
 commands will be executed:

    cl /c -c mod2.c
    lib sub.lib -+ mod2.obj;
    link boss.obj,,,sub.lib;

 The /N switch is used to debug the logic of makefiles without actually
 processing them. In this case, the commands that /N indicates will be
 executed are not the same as those that actually are executed. This is
 caused by the multiple dependencies for sub.lib. If the makefile is
 changed to eliminate the multiple dependency blocks, the /N switch
 will function correctly.

 Microsoft has confirmed this to be a problem in NMAKE versions 1.11
 and 1.12. We are researching this problem and will post new
 information here as it becomes available.

 Sample Code
 -----------

 CFLAGS=/c

 .obj.exe:
         link $<,,,sub.lib;

 all:boss.exe

 boss.exe:boss.obj  sub.lib

 boss.obj:

 sub.lib:: mod1.obj
         lib $@ -+ mod1.obj;

 sub.lib:: mod2.obj
         lib $@ -+ mod2.obj;


 37. U4007 Error Can Be Caused By Not Using Quotation Marks

 Product Version(s): 1.11 1.12
 Operating System:   OS/2
 Flags: ENDUSER |
 Last Modified:  7-NOV-1990    ArticleIdent: Q66646

 If you have a makefile for OS/2 that uses long filenames, you must use
 quotation marks around the long filenames. For instance, if the
 following makefile is used, it will generate the U4007 error message
 ("file name too long:  truncating to 8.3"):

 Sample Makefile
 ---------------

 all: thisisalongfilename.exe

 thisisalongfilename.exe: thisisalongfilename.obj
    link thisisalongfilename.obj;

 thisisalongfilename.obj: thisisalongfilename.c
    cl /c /Tcthisisalongfilename.c

 If the makefile above is changed to the following version, the error
 will not be generated:

 Sample Makefile
 ---------------

 all: "thisisalongfilename.exe"

 "thisisalongfilename.exe": "thisisalongfilename.obj"
    link "thisisalongfilename.obj";

 "thisisalongfilename.obj": "thisisalongfilename.c"
    cl /c /Tc"thisisalongfilename.c"

 For more information on this behavior, please see the README.DOC file
 shipped with Microsoft C version 6.00.


 38. Cause of U4004 Error Message

 Product Version(s): 1.10   | 1.10
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified:  7-NOV-1990    ArticleIdent: Q66649

 The U4004 error message is generated by NMAKE when it encounters
 multiple build dependency blocks for a single target. The following is
 a sample makefile:

 all: tty.exe

 tty.res: tty.rc tty.dlg tty.h
     rc -r tty.rc

 tty.obj: tty.c
    cl -c -AS -Gsw -Os -Zdp tty.c

 wstdio.obj: wstdio.c
    cl -c -AS -Gsw -Os -Zdp wstdio.c

 tty.exe: tty.obj wstdio.obj tty.def
     link /NOD tty wstdio,,,libw slibcew,tty.def
     rc tty.res

 tty.exe: tty.res tty.dlg tty.h
    rc tty.res

 To eliminate the error, use the multiple dependency block separator --
 a pair of colons (::). In the above makefile, the two dependency
 blocks for tty.exe should use this syntax. The multiple dependency
 block separator is documented further on page 109 of the "Advanced
 Programming Techniques" manual, as well as in the online help.

 The following is the corrected makefile:

 all: tty.exe

 tty.res: tty.rc tty.dlg tty.h
     rc -r tty.rc

 tty.obj: tty.c
    cl -c -AS -Gsw -Os -Zdp tty.c

 wstdio.obj: wstdio.c
    cl -c -AS -Gsw -Os -Zdp wstdio.c

 # Note the use of the double colon below and in the next block...

 tty.exe:: tty.obj wstdio.obj tty.def
     link /NOD tty wstdio,,,libw slibcew,tty.def
     rc tty.res

 tty.exe:: tty.res tty.dlg tty.h
    rc tty.res


 39. Link Not Performed During Build or Make

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist1.00 fixlist1.10 fixlist1.11 s_c s_link s_pwb
 Last Modified: 14-DEC-1990    ArticleIdent: Q67482

 During a build inside the Programmer's WorkBench (PWB) (using PWB.COM)
 or while using NMK.COM from the command line, the build operation
 returns successfully but no .EXE file is created.

 This problem may be caused by an incorrectly set COMSPEC environment
 variable. If the COMSPEC environment variable contains any extra
 characters, NMK.COM fails to properly spawn the linker. This affects
 the PWB as well because, under DOS, PWB.COM spawns the build commands
 the same way as NMK.COM. Two examples of COMSPEC environment variables
 that cause this problem are shown in the following:

    COMSPEC=C:\COMMAND.COM /E:512 /P
    COMSPEC=C:\COMMAND.COM;

 Microsoft has confirmed this to be a problem in PWB.COM version 1.00
 and NMK.COM version 1.00. This problem was corrected in PWB.COM
 version 1.10 and NMK.COM version 1.11.


 40. NMK.COM Will Execute PWB.SHL If it Exists

 Product Version(s): 1.00 1.11
 Operating System:   MS-DOS
 Flags: ENDUSER | S_C S_PWB S_QUICKC S_NMK
 Last Modified: 28-DEC-1990    ArticleIdent: Q67776

 NMK.COM will execute the PWB.SHL file if it exists in the subdirectory
 specified by the TMP environment variable. After spawning NMAKE to
 parse the desired makefile, PWB.SHL will be executed as a batch file
 with the commands listed in reverse order.

 This is expected behavior since NMK actually spawns NMAKE with the /z
 option. This instructs NMAKE to preprocess the makefile, writing out
 the commands to be performed into the file PWB.SHL, which is placed in
 the directory pointed to by the TMP environment variable. After NMAKE
 is finished, NMK reads the PWB.SHL file and executes the required
 commands. Once it is finished, the PWB.SHL file is set to 0 bytes or
 deleted.

 To see this behavior, create a file and name it PWB.SHL, placing the
 following two lines in it:

    type listing.txt
    dir > listing.txt

 Place this file in the subdirectory pointed to by the TMP environment
 variable. The following command will spawn NMAKE /z in an attempt to
 parse PROGRAM.MAK, and then execute PWB.SHL:

    nmk /f program.mak

 PWB.SHL will be set to 0 bytes or deleted after all commands have been
 executed.

 If PROGRAM.MAK does not exist, NMAKE will report an error informing
 you of that fact, and then NMK will proceed to execute PWB.SHL as
 described above.

 If you do not have a TMP environment variable, PWB.SHL will be
 executed if it exists in the current subdirectory.

 A side effect to be aware of is the following scenario. If you have
 shelled out of the Programmer's WorkBench to run your program (from
 the Execute selection on the Run menu) and your program hangs, forcing
 you to reboot, a PWB.SHL file will be left in your TMP subdirectory.
 If, after rebooting, you happen to run NMK before going into PWB, NMK
 will find the PWB.SHL file in the TMP subdirectory and execute it,
 causing PWB to be invoked even though you had not explicitly invoked
 PWB since the reboot.


 41. NMAKE Does Not Expand Wildcard Characters

 Product Version(s): 1.11   | 1.11
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | docerr
 Last Modified:  6-FEB-1991    ArticleIdent: Q67794

 Page 107 of the "Advanced Programming Techniques" manual that shipped
 with Microsoft C version 6.00 states:

    NMAKE expands wild cards in target names when it reads the
    description file.

 NMAKE does not expand these wildcard characters when passing the
 wildcard to the compiler. The example given works correctly because
 the compiler expands the wildcard on its own. If you use a compiler
 that does not expand wildcards, the example given will not work.


 42. NMAKE Default Is to Build Only the First Target in a Makefile

 Product Version(s): 1.00 1.01 1.11 1.12 | 1.01 1.11 1.12
 Operating System:   MS-DOS              | OS/2
 Flags: ENDUSER |
 Last Modified: 15-JAN-1991    ArticleIdent: Q40184

 The NMAKE file maintenance utility will only "make" the first target
 in the makefile if no target is explicitly given on the command line.

 Although the following sample makefile will both compile and link
 PROG1.EXE when used with MAKE, it will only compile when the NMAKE
 utility is used. This is an important consideration when porting
 makefiles from MAKE to NMAKE.

 # Sample makefile MAKEFILE1

 PROG1.OBJ : PROG1.C
     cl /Zi /c PROG1.C

 PROG1.EXE : PROG1.OBJ
     link /CO PROG1.OBJ

 If all files are out of date with PROG1.C, and MAKEFILE1 is executed
 with the standard invocation as follows

    NMAKE /f makefile1

 the only command executed from MAKEFILE1 will be the following:

    cl /Zi /c prog1.c

 The LINK command will not be executed because NMAKE did not receive a
 specific target; thus, it only makes the first target in the makefile.
 To achieve the desired results, the desired target (PROG1.EXE) must be
 specified on the NMAKE command-line or the following line could be
 added to MAKEFILE1 (it must be the first line in the makefile):

    ALL : PROG1.EXE

 This pseudotarget "ALL" will be made because it will be the first
 target in the makefile. By using the pseudotarget, it is guaranteed
 that all dependencies will be made because the dependents are always
 out of date. This will force NMAKE to make all targets dealing with
 PROG1.EXE.

 Please refer to the NMAKE documentation shipped with your compiler or
 assembler for more information.


 43. Accessing Environment Variables Inside MAKE or NMAKE Makefile

 Product Version(s): 1.00 1.01 1.10 1.11 1.12 | 1.01 1.10 1.11 1.12
 Operating System:   MS-DOS                   | OS/2
 Flags: ENDUSER | s_make
 Last Modified: 23-JAN-1991    ArticleIdent: Q59141

 You can access environment variables within a MAKE or NMAKE makefile
 in the same way that you access user-defined macros. The only
 difference is that the names of environment variables must be
 capitalized when used in this manner. For example:

 SOURCE=c:\mysource
 # the INCLUDE "macro" will pick up your INCLUDE environment variable

 file.obj : $(SOURCE)\file.c $(INCLUDE)\file.h
     cl /c /Zi /Od $(SOURCE)\file.c


 44. Recursively Calling NMAKE Using the MAKEFLAGS Macro

 Product Version(s): 1.11   | 1.11
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | docerr
 Last Modified: 17-JAN-1991    ArticleIdent: Q68234

 According to page 113 of the "Microsoft C Advanced Programming
 Techniques" manual, if you want to invoke NMAKE recursively, the macro
 $(MAKEFLAGS) can be used to pass the command-line switches to the
 recursively invoked NMAKE. However, the $(MAKEFLAGS) macro will
 contain only the letters of the switches and will not contain the
 actual command-line syntax.

 For example, if the original command line contained "/D /N", the
 $(MAKEFLAGS) macro will contain "DN". This results in NMAKE trying to
 use the $(MAKEFLAGS) macro as the name of the makefile, rather than as
 command-line switches. To use the $(MAKEFLAGS) macro to invoke NMAKE
 recursively, it is necessary to precede it with a hyphen (-) or
 forward slash (/) so that NMAKE uses the macro as a set of
 command-line switches. The documentation should read:

    $(MAKE) -$(MAKEFLAGS)


 45. Placing a Target File in Different Directory Than Dependents

 Product Version(s): 4.07   | 4.07
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | s_make
 Last Modified:  6-FEB-1991    ArticleIdent: Q46354

 To put a target file in a directory different from its dependent file
 in a makefile, you must explicitly name the path for the target file.
 When compiling, use the /Fo switch and a path to place the .OBJ file
 in a different directory from the source. When linking, give the full
 pathname when specifying the .EXE file parameter.

 The following example demonstrates both aspects:

 # MAKE SURE THERE IS A TRAILING BLANK AFTER THE FINAL BACKSLASH
 LONGPATH=e:\c51\binr\
 SHORTPATH=e:\c51\

 pixel.obj:  $(LONGPATH)pixel.c
 # USE /Fo SWITCH TO PUT .OBJ FILE IN DIFFERENT DIRECTORY
   cl /Fo$(SHORTPATH) /c $(LONGPATH)pixel.c

 Note that if you use a macro in the makefile for the pathname (as
 shown above), then you must be sure the final backslash (\) in the
 pathname is followed by a trailing space. If there is no trailing
 space, the backslash will be interpreted as a line-continuation
 character. When you create the makefile, use an editor that will
 preserve a trailing space, such as the Programmer's WorkBench or the
 Microsoft Editor (if you set the "trailspace" switch).


 46. Extmake Switch Does Not Expand Macros

 Product Version(s): 1.11   | 1.11
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | buglist1.11
 Last Modified: 24-JAN-1991    ArticleIdent: Q68379

 The following NMAKE description file shows that macro substitution
 does not occur when using the extmake switch.

 To show the error, set SUBDIR to a subdirectory and execute NMAKE on
 the makefile while in ANOTHER subdirectory.

 Sample Makefile
 ---------------

 SUBDIR = subdir

 foo.exe: $(SUBDIR)\foo.c
      cl %|pfeF

 Resulting command:  cl $(SUBDIR)\foo.c

 The workaround for this particular problem is to replace the extmake
 switch with the predefined macros (that is, $** and $?).


 47. The D Modifier to $? Is Broken in NMAKE Version 1.11

 Product Version(s): 1.11   | 1.11
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | buglist1.11 fixlist1.12
 Last Modified: 24-JAN-1991    ArticleIdent: Q68381

 The D modifier to the $? macro is supposed to return the directory and
 drive portion of the dependent. This does not work properly with NMAKE
 version 1.11. Instead, the full pathname and filename are returned.
 This was corrected in NMAKE version 1.12, which shipped with Microsoft
 COBOL version 4.00.

 Sample Makefile
 ---------------

 all : c:\dos\command.com
    echo The D modifier of $? is $(?D)


 48. $$(@F) Macro Doesn't Work with NMAKE Version 1.01

 Product Version(s): 1.01   | 1.01
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | buglist1.01 fixlist1.11
 Last Modified: 24-JAN-1991    ArticleIdent: Q68388

 The $$(@F) macro illustrated on page 297 of the "Microsoft FORTRAN
 CodeView and Utilities User's Guide" for version 5.00 will not
 function correctly in NMAKE version 1.01. This has been corrected in
 NMAKE version 1.11, which shipped with Microsoft C version 6.00.

 The following is the example from page 297:

 DIR=c:\include
 $(DIR)\global.h $(DIR)\types.h $(DIR)\macros.h: $$(@F)
      !COPY $? $@

 With NMAKE version 1.01, this will only work for the first file in the
 list. Subsequent files are not processed. NMAKE 1.11 correctly copies
 all three files to the c:\include directory.


 49. NMK Displays Only First of Multiple Commands

 Product Version(s): 1.11
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist1.11 S_C S_NMK
 Last Modified:  1-FEB-1991    ArticleIdent: Q68658

 NMK version 1.11 displays only the first of multiple commands it is
 executing when the exclamation point (!) command modifier is used with
 the predefined macro $? or $**.

 The ! command modifier executes the command for each dependent file if
 the command uses the predefined macro $? or $**. The $? macro refers
 to all dependent files that are out-of-date with respect to the
 target. The $** macro refers to all dependent files in the description
 block.

 The sample makefile below echoes each filename to the screen. The
 NMAKE output shows the correct result; each ECHO command is displayed
 and executed. Likewise, the NMK output executes each ECHO command;
 however, only the first command is displayed to the screen.

 Sample Makefile
 ---------------

 ALL: foo1.c foo2.c foo3.c
       !ECHO $**

 Output:

       NMAKE                      NMK
 -----------------         -----------------
       ECHO foo1.c               ECHO foo1.c
 foo1.c                    foo1.c
       ECHO foo2.c         foo2.c
 foo2.c                    foo3.c
       ECHO foo3.c
 foo3.c

 Microsoft has confirmed this to be a problem in NMK version 1.11. We
 are researching this problem and will post new information here as it
 becomes available.


 50. NMAKE Doesn't Allow CD Command That Only Specifies Drive

 Product Version(s): 1.11 1.12 | 1.11 1.12
 Operating System:   MS-DOS    | OS/2
 Flags: ENDUSER | buglist1.11 buglist1.12
 Last Modified:  5-FEB-1991    ArticleIdent: Q68836

 DOS and OS/2 command lines allow you to see the current directory of a
 drive by using the CD (change directory) command. For example, the
 command "CD D:" will return the current directory for the D drive.
 Because this is a valid DOS or OS/2 command, NMAKE should allow you to
 perform the command without error. However, when the NMAKE file below
 is executed, the following message occurs:

    NMAKE: fatal error U1077: 'cd' :return code '1'

 NMAKE treats the CD command as a special case and fails to execute the
 command correctly.

 Sample NMAKE File:

 all:
    cd d:

 Microsoft has confirmed this to be a problem in NMAKE versions 1.11
 and 1.12. We are researching this problem and will post new
 information here as it becomes available.


 51. NMK Macros Do Not Override Environment Variables

 Product Version(s): 1.11
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist1.11
 Last Modified:  6-FEB-1991    ArticleIdent: Q68946

 Macros that are created to redefine environment variables (such as
 INCLUDE, LIB, and PATH) do not work correctly when the description
 file is executed using NMK.COM, rather than NMAKE.EXE.

 The description file below, when executed by NMAKE.EXE, will look for
 the include files in the directory "E:\C\INCLUDE". If the same
 description file is executed by NMK.COM, the include directory will be
 determined by the include environment variable.

 Sample Code
 -----------

 INCLUDE=E:\C\INCLUDE

 FOO.EXE : FOO.OBJ
    link foo.obj;

 FOO.OBJ : FOO.C
    cl /c foo.c

 Note: This example will reproduce the problem correctly only if the
 following conditions are met.

 1. FOO.C exists.
 2. FOO.C contains a line of the form:

       #include <INC_FILE.H>

 3. INC_FILE.H exists in the directory "E:\C\INCLUDE".
 4. INC_FILE.H does not exist in the default include directory.

 Finally, NMK does change the variable for arguments that are in the
 makefile. Therefore, to work around the problem above, you can use the
 following example:

 INCLUDE=E:\C\INCLUDE

 FOO.EXE : FOO.OBJ
    link foo.obj;

 FOO.OBJ : FOO.C
    cl /c /I$(INCLUDE) foo.c






 Microsoft Development Utilities
 =============================================================================


 1. Hyphen in File or Directory Name Causes LIB Error U2155

 Product Version(s): 3.00 3.04 3.07 3.08 3.10 3.11 3.14 3.17 | 3.10 3.11 3.14
 Operating System:   MS-DOS                                  | OS/2
 Flags: ENDUSER | s_lib dash minus sign
 Last Modified: 16-JAN-1991    ArticleIdent: Q67880

 The Microsoft Library Manager utility LIB.EXE does not allow file or
 directory names to contain a hyphen (-) character. If a file or
 directory name containing a hyphen is passed to LIB.EXE, the following
 error will be generated:

    LIB : error U2155: <path> : module not in library; ignored

 Although a hyphen is a valid character for a DOS or OS/2 filename, LIB
 interprets this character as the extraction operator that tells LIB to
 remove an object module from an existing library. Since LIB is
 assuming everything following the hyphen is the name of an object
 module that you want removed, and since this is not an actual module
 name, the U2155 error is generated.

 A common situation where this error may occur is while installing one
 of the Microsoft language products that build combined libraries
 during the installation process. You may receive the U2155 error when
 running a Setup program if you have specified a directory name during
 setup that contains a hyphen. For example, many C users install the C
 compiler in a directory called MS-C, but Setup then fails when LIB is
 called to build the combined libraries in that directory.

 This is expected behavior for LIB.EXE and is the result of the
 established command-line syntax. Unless the command-line syntax is
 changed, the hyphen cannot be recognized as a filespec character
 instead of an operator.


 2. How to Add a Category in QuickHelp

 Product Version(s): 1.70   | 1.40 1.70
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | s_qh s_helpmake
 Last Modified: 24-JAN-1991    ArticleIdent: Q66631

 When creating a help database with HELPMAKE, new categories may be
 added to the Microsoft Advisor help system for use in the QuickHelp
 utility. To add selections that will appear under the QuickHelp
 Categories menu, use the topic "List categories." Under the List
 categories topic, list the selections that need to be added to the
 menu.

 The following is a sample help file:

    File CATEGORY.TXT
    -----------------

       .context List categories
       Category1
       Category2

       .context Category1
       This is the information under the first category.

       .context Category2
       This is the information under the second category.

 For the file CATEGORY.TXT shown above, the HELPMAKE command line will
 appear as follows:

    helpmake /E8 /Ocategory.hlp category.txt

 The choice of /E8 for partial compression is strictly arbitrary in
 this case, and is shown for demonstration purposes only. The maximum
 compression can be achieved by using /E15, and no compression is
 denoted by /E0.

 When the above help database is added to the list of databases for the
 Advisor, the topics "Category1" and "Category2" will be added under
 the Categories menu.

 The items that are placed in the List categories topic should be
 topics that are already defined with ".context" strings; otherwise,
 when the item is selected from the Categories menu, a message will be
 displayed stating that the topic could not be found.

 When using HELPMAKE with the "/C" option, which preserves case
 sensitivity, you must use the string "List categories" exactly. The
 case is important. Failure to use the exact case for each letter will
 cause the Advisor to ignore the categories you have added.


 3. Help Files for QuickC Require Special "Backtrace" Declaration

 Product Version(s): 6.00 6.00a | 6.00 6.00a
 Operating System:   MS-DOS     | OS/2
 Flags: ENDUSER | docerr s_quickc s_helpmake
 Last Modified: 11-FEB-1991    ArticleIdent: Q68678

 When creating a help file using the Microsoft Helpmake utility, !B is
 defined to have the effect of backtracing to the previous help screen
 (if available). However, this is true only when using QuickHelp or the
 Programmer's WorkBench (PWB). If an attempt is made to use this help
 file with QuickC, the link will issue a beep and no backtrace will be
 allowed.

 The documentation included with Microsoft C version 6.00 does not
 reference the exclamation (!) character as being a special function.
 However, on pages 20-21, the "Professional Advisor Library Reference"
 lists all the options available for this command. It also states that
 the !CQ.HB command will allow QuickC version 2.00 compatibility.
 However, it should be noted that the compatibility for this function
 is for QuickC version 2.50 as well. The use of this command gives
 complete compatibility through C versions 6.00 and 6.00a, as well as
 QuickC versions 2.50 and 2.00.

 Another error in the documentation is that !CQ.HB must be in all
 lowercase letters (that is, !cq.hb). HelpMake will not issue an error
 message with an uppercase command, but it will also not allow a
 backtrace to be performed.


 4. Omitting .LIB Extension with BIND Gives U1268 Error

 Product Version(s): 1.10 1.30 | 1.10 1.30
 Operating System:   MS-DOS    | OS/2
 Flags: ENDUSER | s_bind
 Last Modified: 15-JAN-1991    ArticleIdent: Q29135

 Question:

 When I try to bind an application using the BIND utility, I receive
 the following error message:

    BIND : fatal error U1268: duplicate infile given

 This is my BIND command line:

    bind file.exe c:\c\lib\os2 c:\c\lib\api

 What is causing this error?

 Response:

 This error occurs with BIND if you do not specify the .LIB extension
 for the libraries, OS2.LIB and API.LIB. The correct command line is as
 follows:

    bind file.exe c:\c\lib\os2.lib c:\c\lib\api.lib

 Note that BIND version 1.00 displays the same error, but does not
 display an error number.


 5. C 6.00 Utility Support for OS/2 Long Filenames

 Product Version(s): 6.00
 Operating System:   OS/2
 Flags: ENDUSER | s_link s_nmake s_c
 Last Modified: 28-JAN-1991    ArticleIdent: Q58487

 The utilities shipped for Microsoft C version 6.00 provide limited
 support for OS/2 long filenames introduced in OS/2 version 1.20.

 The following is a list of the limitations:

 1. Long filenames with quotation marks are supported via the command
    line. For example:

       "fooo bar"

 2. Embedded quoted long filenames on the command line are not
    supported. For example:

       d:\foo\" bar xyzzy"

 3. Link supports one quoted long filename per argument. For example

       "foo bar"+"bar foo"

    will resemble the following:

       "foo bar+bar foo"

 4. NMAKE provides long filename support inside the makefile with the
    restriction (beyond 1 and 2 above) that target and dependent names
    cannot have a period (.) as the first character (conflicts with
    inference rules). For example:

       ".foo bar.c".".foo bar.exe"


 6. Modifying Existing Help Files with HELPMAKE (QuickC Example)

 Product Version(s): 1.00 1.04 1.05 1.06 | 1.04 1.05 1.06
 Operating System:   MS-DOS              | OS/2
 Flags: ENDUSER | s_helpmake s_qh
 Last Modified: 24-JAN-1991    ArticleIdent: Q40599

 You can add to or change the information in the online help files that
 are accessible from QuickHelp, PWB, and QuickC. To accomplish this, do
 the following:

 1. Decompress the existing help file using HELPMAKE.EXE.

 2. Edit the resulting source listing of the help file.

 3. Recompress this modified file using HELPMAKE.EXE.

 The example below illustrates this process.

 There is a known coding error in the Font function examples in the
 QuickC 2.00 online help. This error occurs in the following code line:

    strcat (fondir, "\*.fon") ;

 This statement should be corrected to read as follows:

    strcat (fondir, "\\*.fon") ;

 To correct this online example in the GRAPHICS.HLP file, do the
 following:

 1. Decompress GRAPHICS.HLP, as follows:

       HELPMAKE /D /Ographics.src /V Graphics.hlp  > decode.log

    /D  Tells HELPMAKE to decode GRAPHICS.HLP
    /O  Tells HELPMAKE to name the output file GRAPHICS.SRC
    /V  Tells HELPMAKE to be verbose in decoding information

    "> decode.log"  redirects decoding information to DECODE.LOG.
    This DOS redirection is not necessary, but is helpful.

 2. Edit GRAPHICS.SRC

    Using an editor of your choice, search GRAPHICS.SRC for the
    code line that contains "\*.fon". When you locate the strcat()
    instruction mentioned above, you will notice that the line already
    correctly reads as follows:

       strcat (fondir, "\\*.fon") ;

    This is the correct coding for the C language. However,
    HELPMAKE.EXE views the backslash, "\", as a flag for instructions.
    Therefore, the first "\" is interpreted and is subsequently not
    viewable in the online help.

    If you intend a "\" to be viewed from within the online help, you
    must type two backslashes. That is why the strcat() instruction is
    displayed in the online help with only one "\".

    To display two successive backslashes from within online help, you
    must type four backslashes in the source file, which HELPMAKE will
    interpret and compress into a helpfile.

    In this example, you would modify the following statement

       strcat (fondir, "\\*.fon") ;

    to read as follows:

       strcat (fondir, "\\\\*.fon") ;

 3. Recompress GRAPHICS.SRC into a help file, as follows:
    (This process may take up to 10 minutes with this file.)

    HELPMAKE /E15 /A: /W128 /Ographics.hlp graphics.src /V > encode.log

    /E15   Tells HELPMAKE to fully compress GRAPHICS.SRC
    /A:    Tells HELPMAKE to view a ':' as an operator
    /W128  Tells HELPMAKE to truncate lines longer than 128 characters
    /O     Tells HELPMAKE to name the output file GRAPHICS.HLP
    /V     Tells HELPMAKE to output verbose encoding information

    "> encode.log" redirects encoding information to ENCODE.LOG
    This is helpful, but it is not necessary.

 4. Copy the new GRAPHICS.HLP to the directory with your other
    help files.

 For further information, refer to the printed or online documentation
 supplied with your version of HELPMAKE.


 7. HELPMAKE Interprets Backslashes as Formatting Flags

 Product Version(s): 1.00 1.04 1.05 1.06 | 1.04 1.05 1.06
 Operating System:   MS-DOS              | OS/2
 Flags: ENDUSER | s_helpmake
 Last Modified: 24-JAN-1991    ArticleIdent: Q40598

 The Microsoft HELPMAKE utility interprets a backslash (\) as a
 formatting flag. If you want to display a backslash in the online
 help, you must type two successive backslashes (\\). The first
 backslash is interpreted; the second is displayed.

 For further information on formatting flags, refer to the HELPMAKE
 documentation in the utilities manual, or the online help supplied
 with your particular compiler.


 8. HELPMAKE: "/A:" Must Be Used When Using Colon (:) Commands

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | s_helpmake s_quickc docerr
 Last Modified: 28-JAN-1991    ArticleIdent: Q42771

 In at least two places in the "Microsoft QuickC Tool Kit" version 2.00
 manual, it is implied that the colon (:) is used as a default for
 HELPMAKE commands. However, it is never explicitly stated that
 HELPMAKE must be invoked with the "/A:" option when encoding the help
 database.

 In fact, for any HELPMAKE colon (:) command to be recognized and
 correctly interpreted during the encoding process, the "/A:" switch
 must be used. For example, to encode the source file HELPTEST.SRC into
 the help database HELPTEST.HLP, the following line should be used
 (where "/A:" specifies the control character; "/E" indicates that the
 file is being encoded, not decoded; and "/O" gives the destination
 filename):

    HELPMAKE /A: /E /OHELPTEST.HLP HELPTEST.SRC

 HELPMAKE options may be in either uppercase or lowercase letters.


 9. Specifying Anchor Blocks in Help Files in RTF

 Product Version(s): 1.05   | 1.05
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | docerr
 Last Modified: 31-JAN-1991    ArticleIdent: Q68688

 Rich Text Format (RTF) is a text format supported by Microsoft Word
 and other word processors. HELPMAKE.EXE can use an RTF file (and the
 RTF symbols) to create help databases for the Microsoft Advisor.
 However, because \a (Anchor text for cross-reference) is not an RTF
 symbol, there is no documented method for creating hyperlinks that
 have more than one word.

 When Helpmake encodes RTF, any text between an RTF code and hidden
 text on a single line becomes a hyperlink. For example, the following

    {\bHyperlink here}{\vhyperlink.dat}

 will cause "Hyperlink here" to be displayed in bold type, and be a
 hyperlink to the topic "hyperlink.dat". To create an anchor block of
 unformatted text, use the \plain code. For example, the following

    {\plainplain hyperlink}{\vhyperlink.dat}

 will cause "plain hyperlink" to be displayed in normal text, and be a
 hyperlink to "hyperlink.dat". If you want to create a hyperlink that
 has only one word, anchor blocks are not needed. Finally, a link must
 fit entirely on one line. You cannot continue invisible or anchored
 text over a line break.

 Sample Code
 -----------

    {\rtf0
    >> open \par
    {\b Include:}   <fcntl.h>, <io.h>, <sys\\types.h>, <sys\\stat.h>

    {\b Prototype:}  int open(char *path, int flag[, int mode]);\par
        flag: O_APPEND  O_BINARY   O_CREAT  O_EXCL  O_RDONLY\par
         O_RDWR    O_TEXT   O_TRUNC  O_WRONLY\par
         (can be joined by |)\par
        mode: S_IWRITE  S_IREAD   S_IREAD | S_IWRITE\par
    \par
    {\b Returns:}    a handle if successful, or -1 if not.\par
      errno:  EACCES, EEXIST, EMFILE, ENOENT\par
    \par
    {\b See also:}   {\plain Example Program}{\v open.ex},\par
    {\ul Template}{\v open.tp}, access, chmod, close,\par
    creat, dup, dup2, fopen, sopen, umask\par
    }

 For more information, see the online help and Chapter 7 in the
 "Microsoft C Advanced Programming Techniques" manual.


 10. RTF Codes \fi<n> and \li<n> Use Twips Instead of Spaces

 Product Version(s): 1.06   | 1.06
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | docerr
 Last Modified: 31-JAN-1991    ArticleIdent: Q68694

 The Rich Text Format codes \fi<n> and \li<n> used for creating help
 files are incorrectly described in the online help. The online help
 states that the code \fi<n> indents the first line of the paragraph
 <n> spaces, and the code \li<n> indents the entire paragraph <n>
 spaces from the left margin.

 However, the value of <n> is the number of twips and not the number of
 spaces. A twip is 1/20 of a point or 1/1440 of an inch; 180 twips
 approximates one space (that is, \li720 will indent the entire
 paragraph four spaces).

 Page 4 of the "Professional Advisor Library Reference" describes the
 RTF codes \fi and \li but does not mention the <n> parameter to indent
 the paragraphs.

 Page 155 of the "Microsoft C Advanced Programming Techniques" manual
 describes the correct syntax for the RTF codes but does not mention the
 format for <n>.


 11. Help Databases Not Properly Decoded by HELPMAKE.EXE

 Product Version(s): 1.03 1.05 1.06 | 1.03 1.05 1.06
 Operating System:   MS-DOS         | OS/2
 Flags: ENDUSER | buglist1.03 buglist1.05 buglist1.06
 Last Modified:  6-FEB-1991    ArticleIdent: Q68989

 When using HELPMAKE.EXE to decode concatenated help databases, you
 must use the "Decode Split" option (/DS). If a concatenated help
 database is decoded with either "Decode" (/D) or "Decode Unformatted"
 (/DU), HELPMAKE may be caught in an infinite loop that will eventually
 fill the hard disk.

 If OS2.HLP is decoded with

    helpmake /D /Ooutfile OS2.HLP

 HELPMAKE will decompress the first database in OS2.HLP over and over
 until either the disk fills up or you stop the program (with a
 CTRL+BREAK, for instance).

 If OS2.HLP is decoded with

    helpmake /DS OS2.HLP

 it is broken into STRUCT.HLP, MACROS.HLP, and TABLES.HLP. These help
 files can then be decoded properly with the /D or /DU option.

 If you don't know how a help file is assembled, the following are the
 steps to take to decompress it:

 1. Save a backup copy of the help file in case of problems.

 2. Rename the help file to "TEMP.HLP".

 3. Split the file as follows:

       HELPMAKE /DS TEMP.HLP

    If the file is not a concatenated database, you will get a single
    file with the name of the help database as it was originally built
    (the internal database name).

    If the file is a concatenated database, you will get individual
    help files with the internal database names. For OS2.HLP, these are
    STRUCT.HLP, MACROS.HLP, and TABLES.HLP.

 4. Decode the resulting files as follows:

       HELPMAKE /D TEMP1.HLP /OTEMP1.SRC
       HELPMAKE /D TEMP2.HLP /OTEMP2.SRC

 Microsoft has confirmed this to be a problem with HELPMAKE.EXE versions
 1.03, 1.05, and 1.06. We are researching this problem and will post new
 information here as it becomes available.


 12. Always Use Latest Version of HIMEM and Other Memory Utilities

 Product Version(s): 2.50 2.60
 Operating System:   MS-DOS
 Flags: ENDUSER | s_codeview s_himem s_ramdrive s_smartdrv
 Last Modified: 15-JAN-1991    ArticleIdent: Q60830

 The newest versions of the memory management utilities (HIMEM.SYS,
 RAMDRIVE.SYS, and SMARTDRV.SYS) should be used at all times. For
 instance, if you use CodeView Version 3.00 (first shipped with
 Microsoft C Version 6.00) and you use a version of HIMEM.SYS earlier
 than what was shipped with the C 6.00 package, you may experience a
 number of problems, including the following:

 1. You may get spurious error messages such as "Not enough extended
    memory available," even if you have more than enough extended
    memory installed.

 2. You may receive the error "CV1319: CodeView initialization error"
    when trying to invoke CodeView.

 3. Your computer may hang or reboot.

 As memory management technology progresses, the Microsoft tools and
 utilities that use the technology are also updated. Therefore, it is
 critical that the latest versions of the memory utilities (HIMEM.SYS,
 RAMDRIVE.SYS, SMARTDRV.SYS, etc.) be installed. Tools such as CodeView
 and the Programmer's WorkBench (PWB) depend on features that are
 available only in the latest versions.


 13. Using LIB to Combine Two Libraries

 Product Version(s): 3.00 3.04 3.07 3.08 3.10 3.11 3.14 3.17 | 3.11 3.14 3.17
 Operating System:   MS-DOS                                  | OS/2
 Flags: ENDUSER | s_lib
 Last Modified: 15-JAN-1991    ArticleIdent: Q25108

 The Microsoft Library Manager utility (LIB.EXE) can be used to combine
 two libraries into one.

 The following is an example of how to add the contents of LIB1.LIB to
 LIB2.LIB in a single LIB command:

    LIB LIB2.LIB+LIB1.LIB;

 You may also have LIB prompt you for input, in which case the input
 and prompts will appear as follows:

 LIB <RETURN>
 Library name: LIB2.LIB <RETURN>
 Operations: +LIB1.LIB <RETURN>

 Note that the .LIB extension is required; otherwise, LIB will assume
 LIB1 is an object module.


 14. Using EXEHDR or EXEMOD to Change the Stack Size of an .EXE

 Product Version(s): 1.00 2.01 | 1.00 2.01
 Operating System:   MS-DOS    | OS/2
 Flags: ENDUSER | s_exehdr s_exemod
 Last Modified:  6-FEB-1991    ArticleIdent: Q25321

 The EXEHDR and EXEMOD utilities can be used to change the stack size
 of a program. EXEHDR runs in both DOS and OS/2, while EXEMOD is an
 older utility that only runs under DOS.

 To view the current size of the stack, no options are used. Both
 EXEHDR and EXEMOD will produce a table of information with a line such
 as the following:

    Initial SS:SP 0000:0800 0

 The offset portion of this line gives the current stack size in hex.
 In this example, the stack size is set at 2K. If you wanted to change
 it to 4K, you could use the /STACK option of EXEHDR or EXEMOD in the
 following way:

    EXEHDR file /STACK 1000

 -or-

    EXEMOD file /STACK 1000


 15. Replacing Real Mode Family API Functions in Bound Applications

 Product Version(s): 1.00 1.10 1.30 | 1.00 1.10 1.30
 Operating System:   MS-DOS         | OS/2
 Flags: ENDUSER | s_bind
 Last Modified: 15-JAN-1991    ArticleIdent: Q39812

 Question:

 How do I create a bound application that uses the system calls in
 protected mode and uses my calls in real mode? The real mode call must
 access global data in my program.

 I would like to bind a program so that it will use the system
 VioGetConfig() function in protected mode, but will use my rewritten
 VioGetConfig() function when run in real mode. Everything compiles and
 links correctly, using either my function or the system function.
 However, my VioGetConfig accesses an initialized global int that is
 declared above the main(), which still compiles and links error free.
 But when I link the main with the system VioGetConfig, then bind the
 .EXE giving it the user's version of VioGetConfig, I get an unresolved
 external on the external global variable from the assembly routine.

 Response:

 The original strategy is probably the best method and should work
 correctly in the general case, that is, in the BIND step, specify the
 user version of VioGetConfig(). The problem is the global int
 variable. BIND does a link of the following:

    API stub loader
    API library modules
    protected-mode image with no symbols

 The key point is that BIND has no access to the internal name space of
 the program. Thus any API routine, including one rewritten by the
 user, cannot see any of the program's data. You should rewrite your
 VioGetConfig() so it does not use the global variable, if possible.
 Otherwise you will have to use one of the methods discussed below.

 Rather than using BIND, do it yourself. In the main program, use code
 such as the following:

     /* Under what operating system we are running ? */

     if (_osmode == DOS_MODE)
     {
         /* We are running under DOS - real mode */

         VioGetConfigUser(); /* User version */
     }
     else
     {
         /* We are running under OS/2 - protected mode */

         VioGetConfig();     /* System version */
     }

 Another way to do this is to build a dual-mode .EXE, as follows:

 1. Build your real-mode program using user VioGetConfig.

 2. Write protected-mode main program using OS/2 VioGetConfig.

 3. In the .DEF file for the protected-mode program, add the following
    statement:

       STUB '<name-of-your-real-mode-app>'

 4. Link your protected-mode application. You will get two programs in one
    .EXE file. In protected mode, the system will load only the
    protected-mode version. In real-mode, the system will load only
    real-mode applications.


 16. Page Size May Cause Big Size Increase When Combining Libraries

 Product Version(s): 3.0x 3.11 3.14 3.17 | 3.11 3.14 3.17
 Operating System:   MS-DOS              | OS/2
 Flags: ENDUSER | s_lib
 Last Modified: 15-JAN-1991    ArticleIdent: Q44896

 Question:

 When I use LIB.EXE to combine my libraries with a third-party library,
 the resultant library is much larger than I expected it to be.

 The following is an example:

     LIB1.LIB    5K   bytes
     LIB2.LIB    250K bytes

     LIB1.LIB + LIB2.LIB  = 305K bytes

 Why is the combined file 50K larger?

 Response:

 This size difference may be the result of different page sizes among
 the libraries being combined. The page size of a library affects the
 alignment of modules stored in the library. When libraries with
 different page sizes are combined, the resultant library uses the
 largest page size from the constituent libraries. Thus, the actual
 increase in file size represents wasted space between modules in the
 library. To reduce the amount of wasted space, you should specify a
 smaller page size for the new library. This may be accomplished by
 using the library manager as follows:

    LIB BIG.LIB /PAGESIZE:16;

 This sets the page size for the library BIG.LIB to 16 bytes.

 As indicated in the library manager documentation, the page size must
 be an integer power of 2 from 16 to 32,768 bytes.


 17. Helpmake Binary Format Is Proprietary

 Product Version(s): 1.00 1.05 1.06 | 1.00 1.05 1.06
 Operating System:   MS-DOS         | OS/2
 Flags: ENDUSER | s_helpmake
 Last Modified: 15-JAN-1991    ArticleIdent: Q48292

 The binary format of the help files produced by the Microsoft Helpmake
 utility is proprietary information, and therefore, not available for
 distribution.


 18. CALLTREE Produces Argument Mismatch with Void Parameter List

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | s_calltree buglist1.00 s_editor
 Last Modified: 15-JAN-1991    ArticleIdent: Q46896

 The CALLTREE utility program included with the Microsoft C version
 5.10 produces the following error message if a void parameter list is
 used for the function foo() and the options -a and -b are specified on
 the command line:

    Argument Mismatch Calling        foo  in  main.c(10)

 Microsoft has confirmed this to be a problem in version 1.00. We are
 researching this problem and will post new information here as it
 becomes available.

 The CALLTREE utility program can be used to produce a tree-like
 structure of function usage. Documentation on the options for CALLTREE
 can be found in the C 5.10 CodeView and Utilities manual in the
 "Microsoft Editor for the MS OS/2 and MS-DOS Operating Systems: User's
 Guide," section on pages 112-114.

 The following program demonstrates the problem:

 void foo(void);   /* prototye contains (void) */

 void main(void)
 {
   foo();     /* function call does not contain (void) */
              /* replace with foo(void); to prevent warning message */
 }

 void foo(void)
 {
   printf("Inside foo\n");
 }

 Invoke CALLTREE by issuing the following command:

 calltree -a -b back.out -w warn.out main.c

 The "warn.out" file will now contain the error message:

    Argument Mismatch Calling        foo  in  main.c(5)


 19. Incorrect Response File Used with LIB Causes U1183 Error

 Product Version(s): 3.1x   | 3.1x
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified: 30-AUG-1989    ArticleIdent: Q47016

 Question:

 I want to use a response file entitled LIB_OPS with the library
 manager just for specifying my library operations. When I invoke LIB
 with the command

    LIB mylib.lib @lib_ops, mylib.lst;<cr>

 it generates the following error:

    LIB : fatal error U1183 : 'cannot open response file'

 However, when I invoke LIB using the command prompts and supply my
 response file for the Operations prompt as follows, everything works
 correctly:

     .
     .
     Operations: @lib_ops<cr>
     .
     .

 What differentiates the two cases?

 Response:

 Using a response file on the command line of the library manager
 requires that the response filename be delimited correctly. This is
 mandated by the command-line parser, which considers trailing argument
 delimiters such as a comma or semicolon to be part of the response
 filename. Consequently, the parsing of the unknown filename prohibits
 DOS from locating and opening the correct response file. When a
 response file is detected on the LIB command line (via the "@"
 character), the command interpreter parses following characters as the
 filename argument until a DOS delimiter, either a space character or a
 carriage return, is encountered. Hence, LIB commands such as

    LIB @response;<cr>
    LIB mylib.lib @response, mylib.lst;<cr>

 generate the U1183 "cannot open response file" because the file
 "response" is actually parsed as "response;" and "response,",
 respectively, neither of which exist in the current working directory
 or those directories searched for by the DOS APPEND command. However,
 correctly delimiting the end of the response file argument with a
 space or carriage return allows the following LIB commands to work
 correctly:

    LIB @response ;<cr>
    LIB @response<cr>
    LIB mylib.lib @response ,mylib.lst;<cr>

 When operating the library manager with a response file containing
 information for one or more of the LIB arguments, it must be invoked
 in one of the following two ways:

 1. With the response file supplied on the LIB command line and the
    file's final character delimited correctly (by a space or carriage
    return).

 2. With no command line arguments and the response file used as a
    reply to the appropriate LIB command prompt.

 The first method is discussed and illustrated in the information
 above. The second method of using the library manager prompts is
 equally effective. However, when supplying a response file to a LIB
 command prompt, the filename must be delimited correctly as in the
 aforementioned, or the U1183 error occurs. The following example
 demonstrates the generation of this error due to incorrect delimiting
 of the response file:

 LIB<cr>

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

 Library name: mylib.lib<cr>

 Operations: @response;<cr>

 LIB : Fatal Error U1183:  Cannot open response file

 Correcting the response file argument to the Operations prompt as
 follows eliminates the problem:

 Operations: @response<cr>

 or

 Operations: @response thisisextrajunkbutwillworkcuzofthe<space>delimiter


 20. LIB Version 3.17 Available for Increased Library Capacity

 Product Version(s): 3.17   | 3.17
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | appnote SS0329.ARC s_lib
 Last Modified: 17-DEC-1990    ArticleIdent: Q66569

 The Microsoft Library Utility (LIB.EXE) version 3.17 is available to
 registered users of Microsoft language products who are experiencing
 difficulty creating libraries with older versions of LIB due to
 capacity limits. If you are the registered owner of a Microsoft
 language product, you may obtain LIB 3.17 as an application note from
 Microsoft Product Support Services by calling (206) 637-7096.

 LIB 3.17 can also be found in the Software/Data Library by searching
 on the keyword SS0329, the Q number of this article, or S12776. SS0329
 was archived using the PKware file-compression utility.

 Older versions of the Microsoft Library Manager are somewhat limited
 as far as the size of a library that can be created or the number of
 modules or symbols that a library can contain. These limits are not
 specific because the actual limits for any particular library are the
 result of a combination of factors including the number of modules,
 the number of symbols, the page size used, and the order in which
 items are added to the library.

 One indication of a library capacity problem is if a previously usable
 library suddenly causes the linker to generate the error message
 "L1101: invalid object module" after some additions to the library.

 Newer versions of LIB, such as version 3.17, have improved capacity
 over the earlier versions. Thus, libraries with a greater number of
 object modules, and/or a greater overall size, should be possible,
 even though the exact limits are still specific to each particular
 library.

 No documentation for the Library Manager is supplied with the
 application note because its usage and commands are identical to
 previous versions. Any questions concerning the usage, command syntax,
 or options for this version can be addressed by referring to existing
 LIB documentation.


 21. "Packed File Corrupt" Error

 Product Version(s): 3.x 4.x
 Operating System:   MS-DOS
 Flags: ENDUSER | s_link s_c h_fortran s_pascal s_quickc h_masm b_basic
 Last Modified: 12-FEB-1991    ArticleIdent: Q58225

 Question:

 When I attempt to run my program, I get the error message "Packed File
 Corrupt." What causes this error and how can I run my program?

 Response:

 The error is caused by a problem in the packed EXE loader that is
 incorporated into EXEPACKed files. This causes incorrect loading of
 packed files. The problem only occurs when the program is loaded into
 memory before the first 64K byte boundary.

 CHKDSK reports more than 589,824 bytes of free memory. Typically, this
 problem tends to occur with DOS Version 3.30 when you try to free up
 more memory by setting the files and buffers in your CONFIG.SYS file
 to less than their default values.

 To correct this problem, force DOS to load the program above the first
 64K of memory by increasing the amount of memory DOS uses. One way to
 do this is to fill up the first 64K segment with one or more copies of
 COMMAND.COM.

 You can also use copies of COMMAND.COM to diagnose the problem. Spawn
 a new command interpreter by typing "COMMAND" at the DOS prompt. Then
 try to run the program. Keep spawning copies of COMMAND.COM until the
 program runs. When the program runs, you have successfully filled the
 first 64K.

 If this method works, you may resolve the problem in a more permanent
 manner by increasing the number of files and buffers in the CONFIG.SYS
 file, and rebooting your machine.

 The EXEPACK utility compresses sequences of identical characters from
 a specified executable file. It also optimizes the relocation table,
 whose entries are used to determine where modules are loaded into
 memory when the program is executed. When the program is executed, it
 must first unpack the file into memory. It is the unpacking code that
 unpacks incorrectly and generates the "Packed File Corrupt" error.

 For more information on the EXEPACK utility, refer to Page 321 in the
 "Microsoft CodeView and Utilities" manual shipped with C version 5.10.
 For information on the /EXEPACK linker option, refer to the utilities
 manual or online help shipped with your particular version of the
 compiler or assembler.
 Additional reference words: b_quickbasic o_msdos h_mouse h_mspbrush


 22. CVPACK May Lose Type Information in Large Files

 Product Version(s): 2.01 3.01 | 2.01 3.01
 Operating System:   MS-DOS    | OS/2
 Flags: ENDUSER | s_cvpack s_codeview
 Last Modified:  5-FEB-1991    ArticleIdent: Q58718

 Certain type information such as that required to expand a structure
 using the "?? <structurename>" command in CodeView can be lost in
 large files when using CVPACK.

 Running CVPACK on very large executables may remove such information
 from the file. Before running CVPACK, internal information can be
 viewed and members can be expanded on structures; after CVPACK, only
 the structure's address is viewable.

 The reason this occurs is that CVPACK is stripping out information
 that CodeView needs to correctly display pointers to far data.

 In this case, CodeView attempts to provide information on the pointers
 to far data in the structure, but the information it gives is not
 correct. Observing the change in the structure's segment address
 before and after using CVPACK shows that this address changes while
 the offset address remains the same. Therefore, the correct
 information cannot be displayed, and CodeView emits a warning beep
 instead of showing the expanded structure elements.


 23. BIND Error "Import By Ordinal Not Defined: DOSCALLS.5"

 Product Version(s): 1.00   | 1.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | s_bind
 Last Modified: 27-DEC-1990    ArticleIdent: Q58929

 Question:

 When I use BIND version 1.00 to bind my OS/2 program, the following
 error message is returned:

    Import by ordinal not defined: DOSCALLS.5

 I bind my program with the following:

    BIND hello.exe -o hellob.exe

 Why do I get that error when I call FAPI functions by name and not
 their ordinal numbers?

 Response:

 The above error occurs because DOSCALLS.LIB must be listed on the BIND
 command line. Bind automatically searches for API.LIB and OS2.LIB
 (using the LIB environment variable), but not DOSCALLS.LIB.

 When using bind, DOSCALLS.LIB must be explicitly listed on the command
 line and the LIB environment variable must point to API.LIB and
 OS2.LIB. For example:

    BIND hello.exe c:\c510\lib\doscalls.lib -o hellob.exe


 24. LIB.EXE Failure When Trying to Build Large Libraries

 Product Version(s): 3.11   | 3.11
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | s_lib appnote
 Last Modified: 17-DEC-1990    ArticleIdent: Q59892

 When using versions of the Microsoft Library Manager (LIB.EXE) earlier
 than Version 3.14 to try to build large libraries with many symbols
 and modules, the LIB program may fail due to capacity limits.

 If you encounter various failures or random errors when trying to
 build a large library (for example, the Greenleaf Libraries), you
 should contact Microsoft Product Support at (206) 637-7096 to obtain a
 more recent version of LIB.EXE.

 LIB.EXE is shipped with all Microsoft language products for building
 and maintaining run-time libraries. Earlier versions of LIB run into
 problems when the library size approaches 200K or larger, but the
 point at which LIB may fail varies widely. LIB capacity is
 unpredictable because it is affected by such items as the number of
 symbols, the number of modules, and the length of symbol names.

 Sometimes, just changing the order in which modules are added to a
 large library will resolve the problem (or at least alter the point of
 failure or the particular errors generated). Some of the errors
 reported from capacity failures are U1174, U1188, and U1189.

 Errors such as U1174 and U1189 are documented only as being problems
 for which you should contact Microsoft Product Support. In general,
 these errors indicate major LIB capacity overflow problems and the
 best workaround is to update to a newer version of LIB.EXE.


 25. Bound Program Works Under OS/2, but Hangs Under DOS

 Product Version(s): 1.10   | 1.10
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | s_bind h_fortran s_link
 Last Modified: 15-JAN-1991    ArticleIdent: Q61469

 If you use BIND version 1.10 and the OS/2 Linker/2 Version 1.20, the
 program will bind error-free and will run correctly under OS/2, but
 will hang the machine if run under DOS.

 BIND version 1.10 creates an executable that hangs under DOS but runs
 correctly in OS/2 if the program is linked with the OS/2 linker
 version 1.20. Using BIND 1.10 with LINK version 5.03 resolves this
 problem, and using BIND 1.20 or later with the OS/2 linker also
 creates a valid executable for DOS and OS/2.


 26. Using /help Option with RM.EXE Displays EXP.EXE Online Help

 Product Version(s): 1.01   | 1.01
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | s_rm s_pwb s_editor docerr
 Last Modified: 17-DEC-1990    ArticleIdent: Q61967

 The utility program RM.EXE version 1.01 displays the wrong help screen
 when invoked with the /help option. The /help parameter is designed to
 invoke the Quick Help (QH) utility in order to display the online help
 for RM.EXE. Because the wrong utility name was written into the RM.EXE
 file, the help screen displayed for RM with /help is the help
 information for the EXP utility.

 This error is due to a problem in the RM.EXE file, rather than being a
 problem in the help files; thus there is no easy way to correct this
 problem. To access the correct help information for RM, one of the
 following methods may be used:

 1. Invoke Quick Help directly. Use RM as the parameter to indicate RM
    as the item on which to find help (for example, type QH RM at the
    DOS or OS/2 prompt).

 2. Invoke RM with the /help option (for example, type RM /help at the
    prompt) and when the EXP help screen appears, page down to the
    bottom where there is a link labeled "RM Command." Select this link
    and the RM help screen will be displayed.

 3. Help on RM can be accessed from within the Programmer's WorkBench
    (PWB) by selecting "Miscellaneous" on the main Help Contents screen
    (in the box titled Microsoft Utilities), and then selecting "RM
    Command" from the submenu.


 27. Helpmake Version 1.05 May Not Decode All Formatting

 Product Version(s): 1.05   | 1.05
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | s_helpmake buglist1.05 fixlist1.06
 Last Modified: 23-JAN-1991    ArticleIdent: Q64792

 HELPMAKE version 1.05 (shipped with Microsoft C version 6.00) does not
 decode all formatting information in help files decoded with the /D
 option. HELPMAKE version 1.03 (shipped with the OS/2 1.20 SDK) works
 as expected.

 This lack of decoding will result in no bold, green, italic, or
 underline formatting in help files that are compressed again with
 HELPMAKE.

 Microsoft has confirmed this to be a problem in HELPMAKE version 1.05.
 This problem was corrected in HELPMAKE version 1.06. HELPMAKE 1.06 was
 shipped with the Microsoft Advisor Library.

 Example
 -------

 The "\i" and "\p" options are not decoded in the sample below. This
 excerpt is from PWB 1.00 version of the PWB.HLP file.

 Note: Nonprintable characters are removed from these examples.

 From HELPMAKE version 1.03:

    +------- Browse Menu ---------+
    | \i\a\pGoto Definition...\v@L8001\v\i\p | Finds definition of symbol

 From HELPMAKE version 1.05:

    +------- Browse Menu ---------+
    | \aGoto Definition...\v@L8001\v | Finds definition of symbol


 28. QuickHelp Duplicate Search Brings Up Wrong Help

 Product Version(s): 1.70   | 1.70
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | s_qh buglist1.70 SDK
 Last Modified: 17-DEC-1990    ArticleIdent: Q67234

 In QuickHelp, if you select Duplicate Search from the View menu and
 enter a search string containing a wildcard, all the topics that match
 that string should appear. In some cases, however, all of the
 occurrences are NOT displayed, which causes the help topics to be out
 of sync with the information they bring up. When this problem occurs,
 you may select a topic, and help on a different topic will be
 displayed.

 One example of this problem occurs when searching on _dos* with the
 CLANG.HLP help file that comes with Microsoft C version 6.00. Another
 example is found when searching for wm_* in the SDKADV.HLP help file
 that comes with the Windows 3.00 Software Development Kit. In both
 cases, if you go to the end of the list of topics and bring up the
 information, the wrong help will be displayed.

 Microsoft has confirmed this to be a problem in QuickHelp version
 1.70. We are researching this problem and will post new information
 here as it becomes available.


 29. Hyperlink for MakeProcInstance in SDKADV.HLP Incorrect

 Product Version(s): 1.70   | 1.70
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | s_qh docerr
 Last Modified: 17-DEC-1990    ArticleIdent: Q67397

 When accessing the function MakeProcInstance() from the index in
 QuickHelp version 1.70, the help screen for Windows DataTypes is
 presented instead. This behavior may be duplicated by following the
 procedure outlined below:

 Start QuickHelp with an argument to get help on any windows topic, as
 follows:

    qh wndclass

 This will bring up the help screen for the wndclass structure. Now
 click the right button on the QuickHelp index, and then on the
 alphabetical section for M. At this point, if help for
 MakeProcInstance() is chosen, QuickHelp will, instead, bring up the
 help screen for Windows Data Types.

 If the SDKADV.HLP file is decoded using HELPMAKE, as follows

    helpmake /D /Osdk.doc sdkadv.hlp

 it becomes obvious that the reason for this error is that the
 hyperlink for MakeProcInstance() appears as follows in the decoded
 help file:

    \aMakeProcInstance function \vDatatypes\v

 This causes QuickHelp to display the DataTypes help screen instead of
 help for the appropriate function.

 This problem can be corrected by changing the above line to read as
 follows:

    \aMakeProcInstance function \vMakeProcInstance\v

 The SDKADV.HLP file must then be recompressed, as follows:

    helpmake /E0 /T /Osdkadv.hlp sdk.doc

 The choice of /E0 indicates no compression, and is strictly arbitrary
 in this case. If maximum compression is desired, the 0 argument to the
 /E switch may be left off, or /E15 may be specified.


 30. The Syntax for STACK Is Incorrect in EXEHDR Usage Statement

 Product Version(s): 2.01   | 2.01
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | docerr s_exehdr
 Last Modified: 17-DEC-1990    ArticleIdent: Q67793

 When the /? parameter is used for EXEHDR, a listing is displayed
 detailing the various switches accepted by EXEHDR. This list
 incorrectly indicates that the /STACK switch must be followed by a
 hexadecimal number between 0h and ffffh. In reality, the /STACK switch
 must be followed by either a decimal number between 0 and 65535 or a
 hexadecimal number using C notation (0x0 - 0xffff).

 If any other format is used, EXEHDR will return the following error
 messages:

    EXEHDR: error U1110: malformed number xxxx
    EXEHDR: error U1115: option /STACK:xxxx ignored






 Microsoft Mouse
 =============================================================================


 1. Availability of MENU.COM

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified:  4-NOV-1988    ArticleIdent: Q28420

 I have obtained a file with the .MNU extension for a third party
 application that requires a file from Microsoft called MENU.COM.

 If you have a mouse with driver Version 6.14, the MENU.COM file will
 be on your Mouse Setup Disk.

 If you have a version between Version 6.00 and Version 6.14, call
 Microsoft Product Support (206) 454-2030 about obtaining MENU.COM.

 If you have a version prior to Version 6.00, you will have the file on
 your System Disk.


 2. Network and Mouse Conflicts

 Product Version(s): 6.x 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified:  4-DEC-1988    ArticleIdent: Q28421

 The bus mouse is interrupt selectable using the J4 jumper block
 located on the INPORT interface card. Make sure the netcard is not
 using the same interrupt; if your network card is using the same
 interrupt, it will crash when the mouse driver installs.

 The bus mouse uses its own I/O address (23c-23f). On the current
 interface cards this can be changed to the lower four bytes by
 selecting secondary INPORT (address 238-23b) over PRIMARY on the J3
 jumper setting. (note: moving the card to another slot may in
 addition solve the problem).

 If the above does not solve the problem or if you have the serial
 mouse, change the driver loading order or disable the driver (mouse
 off) when using the network.

 Contact the manufacturers of your netcard to see if they know of the
 above problem.


 3. IRQ Settings and Mouse Installation

 Product Version(s): 1.x 2.x 3.x 4.x 5.x 6.x 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 19-SEP-1988    ArticleIdent: Q12230

 The jumper on the bus mouse should be checked before the card is
 installed in any computer, especially if the card is moved from one
 machine to another. The board's jumper controls which interrupt
 request (IRQ) line is used. IRQ lines are used to facilitate
 information transfer from such I/O devices as disk controllers and
 serial ports. The jumper avoids IRQ conflicts with other devices
 already installed in the computer. Under each pair of pins on the card
 is a number between 2 and 5 (inclusive). The jumper selects the IRQ
 line. Microsoft ships the boards with the jumper set to IRQ 2, for
 installation in a typical IBM PC or PC XT. Because IBM changed the IRQ
 architecture in the PC AT by using using IRQ 2 for the second IRQ
 controller, the bus mouse jumper is usually set to IRQ 5 on an AT.

 While these jumper settings are correct for most installations, you
 should verify which (if any) IRQ lines are being used by every device
 already installed in the machine. There can be only one active device
 per IRQ line. Refer to the technical manuals for each manufacturer's
 product or contact the manufacturer directly for this information. The
 following is an IRQ allocation table as defined in the IBM PC and AT
 technical reference manuals (other manufacturers' software, hardware
 and add-on boards must follow this convention in order to be IBM
 compatible):

                                         PC-AT
 IRQ Line        PC, PC-XT       CTLR 1          CTLR 2

     0             Timer         Timer     | IRQ8  Clock
     1            Keyboard      Keyboard   | IRQ9  Redirected IRQ2
     2            Reserved       CTLR 2 <--| IRQ10 Reserved
     3              COM2          COM2     | IRQ11 Reserved
     4              COM1          COM1     | IRQ12 Reserved
     5           Hard disk        LPT2     | IRQ13 Coprocessor
     6          Floppy disk   Floppy disk  | IRQ14 Hard disk
     7             LPT1-3         LPT1     | IRQ15 Reserved

 Because the mouse can be jumpered in the IRQ range of 2 through 5 and
 there can be only one active device per IRQ line, the bus mouse can be
 installed only if at least one of these lines is free.

 For example, a bus mouse is to be installed in an IBM PC-AT with an
 IBM PC-AT Serial/Parallel Adapter configured as COM1 and LPT1,
 respectively; a Color Graphics Adapter; and a multi-function card with
 128K of memory and a serial port configured as COM2. On this computer,
 there is only one IRQ line still available on IRQ controller 1: IRQ 5.
 IRQ 2 is used by the AT's second IRQ controller and IRQ lines 4 and 3
 are used by COM1 and COM2. The CGA does not use an IRQ line and the
 parallel port uses IRQ 7, which falls outside of the mouse's range.
 The bus mouse should be jumpered for IRQ 5, thereby using the last IRQ
 line in the normal IRQ range of 0 through 7 of the first IRQ controller.
 The user of this computer should be aware of this for future
 expansion.

 The Enhanced Graphics Adapter (EGA) is now becoming a popular display
 card for PCs and XTs. The EGA includes a hardware feature that allows
 software to enable interrupts on IRQ2 to indicate the start of
 vertical retrace. Therefore, if an EGA and bus mouse are installed in
 a PC or XT, IRQ2 is no longer available for the mouse. In a full XT
 with a hard disk, two serial ports, an EGA, and a bus mouse, there
 will be an IRQ line overlap between two devices. Therefore, one device
 will have to be sacrificed to free up an IRQ line for the bus mouse.
 This is not a design deficiency of the bus mouse; it is a fundamental
 design restriction in the PCs and XTs.

 As discussed above, there are only eight IRQ lines in the PC and XT,
 of which four are used up by the motherboard and other standard
 equipment. The other four lines go quickly. Almost all expansion cards
 require that a free IRQ line be available, such as the following:

 1. Network cards
 2. Bisync communication cards
 3. Tape back-up units
 4. Some clock/calendar hardware
 5. Serial communication cards
 6. EGAs
 7. Emulation boards
 8. Hard disk controllers

 There are more desirable devices to install in a machine than IRQ
 lines to handle them. To help relieve the crowding of IRQ lines, the
 IBM AT includes a second IRQ controller with seven more lines.
 Currently, hardware is evolving to take advantage of the new AT
 architecture.

 Once the hardware is installed, the software must be loaded. When the
 mouse driver loads, using either MOUSE.SYS from CONFIG.SYS or
 MOUSE.COM from a batch file or the keyboard, the file will be loaded
 into memory and the driver will then install itself. This installation
 requires a few seconds. Various operations are undertaken, including
 mouse hardware initialization. This is the primary reason for the
 delay before the mouse installation message appears.

 If the error message "MOUSE: Microsoft mouse not found!" appears,
 there can be a number of hardware-related causes, such as a broken
 mouse; however, the problem more likely is an IRQ contention problem
 either between the mouse and another device or between the serial
 ports.

 Typical bus mouse related problems are between the mouse and the hard
 disk controller, i.e., bus mouse jumpered on IRQ 5 in an XT or IRQ 2
 in an AT. The common symptom for this problem is the inability to
 perform a warm boot (CTRL+ALT+DEL). If the bus mouse is jumpered on
 the same line as a serial port, network card, or emulator card,
 irregular and unreproducible system crashes can occur. In Windows,
 with a bus mouse doubled up on the IRQ line used by a modem, the mouse
 will "go away" when communications software is run.

 The standard isolation procedure is to verify IRQ-line usage and if no
 problems are uncovered, the next step is to remove as much hardware as
 possible. In this way, the conflict should be uncovered between
 particular devices and a resolution of the problem will follow.


 4. Bus Mouse and Cipher Tape Drive Card

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 31-AUG-1989    ArticleIdent: Q46793

 Problem:

 When using the Microsoft Bus Mouse in an AST Premium 386/25, I got the
 following error message after I installed a Cipher Tape drive card:

    Bad or missing interrupt jumper

 Response:

 This problem occurred because the interrupt and primary/secondary
 jumper settings were wrong. To correct this problem, change J4 to
 interrupt 2, and J3 to secondary inport.


 5. Types Of Mice Available: Serial, Bus, and InPort

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 19-JUL-1988    ArticleIdent: Q28738

    Version 1.00 of the new white-button mouse is available in three
 varieties; there are no noticeable differences in function or speed.
 The type of mouse you want depends on the available resources of your
 system.
    The PS/2 Serial mouse will work in any IBM PS/2 mouse port or in
 any standard IBM 9- or 25-pin serial port. The PS/2 Serial mouse is
 recommended if you own an IBM PS/2 machine or have an available COM1:
 or COM2: serial port on your system.
    The Bus mouse has its own interface card, which includes the
 Microsoft InPort interface. It can be used with any IBM PC, XT, AT, or
 PS/2 model 25/30 with an available 8- or 16-bit slot. The Bus mouse is
 interrupt selectable (2 through 5), and frequently saves your serial
 ports for other uses.
    The InPort mouse is the same as the Bus mouse except that it does
 not come with a Microsoft InPort interface-equipped interface card.
 You must have the Microsoft InPort interface within your system (e.g.
 the MACH 20 has built-in InPort technology).


 6. Programming the Mouse Driver Versus Writing One

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified:  4-NOV-1988    ArticleIdent: Q28739

 If you plan to write an application with built-in mouse support,
 obtain the "Microsoft Mouse Programmer's Reference Guide." The manual
 includes a mouse library (for the Microsoft Compilers) and
 documentation on programming the mouse driver.

 Microsoft recommends that you program the mouse driver, rather than
 write your own mouse driver. This will maintain compatibility over any
 changes in future mouse hardware.

 If you need to write your own mouse driver, you can obtain the InPort
 Application Note (which is used with the Bus mouse) by calling
 Microsoft Product Support Services at (206) 454-2030.

 The Serial mouse protocol may be obtained by writing a formal request
 to our Mouse Product Manager (or contacting our Mouse ISV department),
 giving supported reasons for bypassing our mouse driver.


 7. Obtaining Hosiden Connectors Used with the Bus Mouse

 Product Version(s): 6.0 6.02 6.10 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 21-APR-1988    ArticleIdent: Q28740

    The Hosiden connectors and sockets, which are used with the Bus
 Mouse with InPort hardware, can be obtained from HB Associates at
 1-800-423-3014.


 8. How to Deallocate or Disable the Mouse Driver

 Product Version(s): 6.0 6.02 6.10 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 21-APR-1988    ArticleIdent: Q28741

    If the MOUSE.COM driver is installed, the Mouse Off command will
 deallocate the driver from memory if there were no other
 memory-resident programs loaded after it.
    If the MOUSE.SYS driver was installed, the Mouse Off command will
 only disable the driver and not deallocate.
    Although the mouse driver is deallocated or disabled, the mouse
 hardware will continue to send interrupts.



 9. Keyboard Styles for IBM and IBM Compatibles

 Product Version(s): 1.00   | 1.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | non-numeric
 Last Modified: 31-AUG-1989    ArticleIdent: Q46918

 Use of the Microsoft Mouse menus is sometimes affected by the style of
 computer keyboard being used. The following are some major versions
 the IBM and IBM-compatible keyboard:

 1. The "standard" keyboard came with the original IBM PC. This
    keyboard includes a numeric keypad on the right-hand side and 10
    function keys across the top of the keyboard.

 2. The "extended" keyboard adds the F11 and F12 function keys to the
    standard keyboard.

 3. The "expanded" keyboard widens the standard keyboard and reproduces
    the nonnumeric keys and the cursor keys in the additional space.


 10. Leading Edge Model D Error "Unexpected SW Interrupt 33"

 Product Version(s): 6.x 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified:  5-JUN-1988    ArticleIdent: Q29466

    The error message "Unexpected SW Interrupt 33" can occur on some
 Leading Edge Model D computers when installing a mouse driver.
    You usually can continue after this error message has appeared by
 typing C to continue. For a patch, call Leading Edge technical support
 at (617) 821-4300.


 11. Serial Mouse: "Driver Not Installed--Mouse Not Found" Message

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 28-APR-1988    ArticleIdent: Q29201

    A "Driver not installed--Mouse not found" error message usually
 pertains to a possible hardware problem.
    When isolating the source of the problem, first boot from a
 "vanilla" DOS (i.e., no AUTOEXEC.BAT or CONFIG.SYS files), then
 install the mouse driver manually from the Mouse Setup Disk.
    If the error remains, check your hardware set up for possible
 hardware conflicts or incorrect serial port configuration before
 determining if you have a possible faulty mouse.
     Your serial ports must follow an IBM standard and be configured as
 follows:

 COM1 using IRQ4 and configured as DTE (data terminal equipment).
 COM2 using IRQ3 and configured as DTE (data terminal equipment).

    The serial mouse does not work on serial ports configured as COM3
 or COM4. If you have only one serial port and it is configured as
 COM2, the mouse driver usually installs but does not work. Configure
 the port as COM1.
    If you have checked your configuration and the mouse driver does
 not install, checking the mouse on two machines is a good isolation
 test.


 12. Mouse Driver Installs but Mouse Does Not Work

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified:  5-JUN-1988    ArticleIdent: Q29202

    If the mouse driver is installed, but the mouse does not work, the
 problem may be due to one of the following problems:

    1. A hardware conflict
    2. A software conflict
    3. A faulty mouse

    If you have a serial mouse, make sure that your serial ports are
 correctly configured.
    To rule out a software conflict, boot from a "vanilla" DOS (i.e.,
 no AUTOEXEC.BAT or CONFIG.SYS files) and manually install the mouse
 driver from the Mouse Setup disk by typing Mouse.
    Problems can occur if the mouse driver is installed on a device
 other than the mouse. This is true in cases where a noisy bus causes
 the driver to install for a bus mouse, or a device such as a modem
 causes the driver to think a serial mouse is being used.
    If you suspect the driver is not installing on the correct port,
 use the mouse switches to direct the driver to the specific port.
    For example, if your mouse is on COM2, load the mouse driver with
 the following command:

    MOUSE /C2  <- install driver on COM2

    If you have a bus mouse, check the jumper settings for a possible
 interrupt conflict, an I/O address conflict, or expansion slot problems.
   If the problems continue, isolate the problem on another machine
 before determining if you have a faulty mouse.


 13. Serial Mouse Pin-Outs

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified:  5-JUN-1988    ArticleIdent: Q29204

    The serial mouse includes a 9- and 25-pin adapter cable to work with
 a standard 9- or 25-pin IBM serial port. The following are the pin-outs
 of the mouse cables:

                   Connectors

    Function    9 pin      25 pin

    RXD         pin 2      pin 3

    TXD         pin 3      pin 2

    RTS         pin 7      pin 4

    GND         pin 5      pin 7

    DTR         pin 4      pin 20

    The serial mouse is a data communication equipment (DCE) device,
 and is a female device (i.e., it has holes in its connectors). Because
 it is a DCE device, the port's functions should be one to one when
 making a cable for a nonstandard serial port.
    For example, the mouse's RXD should connect to your serial port's
 RXD and the mouse's TXD should connect to the serial port's TXD. This
 is true for other functions as well.


 14. Bus Mouse May Not Work on IRQ 2 on a 386 with OS/2

 Product Version(s): 6.x 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified:  6-SEP-1988    ArticleIdent: Q29279

 The OS/2 mouse driver MOUSEA04.SYS will not install if you use the IRQ
 2 setting for OS/2 and a Wyse 386. MOUSEA03.SYS will install, but
 will not work in OS/2. The mouse works properly in DOS.

 OS/2 seems to be more sensitive to the IRQ usage. This problem occurs
 with both the old and new bus mice. To work around the problem, use
 another interrupt other than 2 on the 386.

 Although IRQ2 is not recommended for ATs or 386s, the mouse seems to
 work without any problems in the DOS environment (using all other
 interrupts); however, this does not seem to be the case in OS/2.


 15. Serial Mouse May Fail with an Older AT&T 6300

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified:  1-AUG-1988    ArticleIdent: Q28681

    There have been some reports that the mouse driver may not install
 correctly with a serial mouse connected to an older AT&T 6300. Using
 the "/C1" or "/C2" switch often solves the problem. If the problem
 continues, check the ROM date and upgrade the ROM if you are using an
 older one. AT&T recommends Version 1.43 ROM or later. Contact AT&T at
 (800) 222-7278 for ROM upgrade costs.


 16. Mouse EGA Register Interface

 Product Version(s): 6.x 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified:  4-NOV-1988    ArticleIdent: Q29467

 An application note concerning the Mouse EGA Register Interface can be
 obtained by contacting the Microsoft Product Support Services Hardware
 Group at (206) 454-2030.

 The Microsoft Mouse EGA Register Interface is a library of nine
 functions. It can be called from assembly language programs or high
 level languages, such as FORTRAN, Pascal, C, and compiled BASIC. Its
 functions allow you to do the following:

 1. Read and write to one or more of the EGA write-only registers.

 2. Define default values for the EGA write-only registers or reset the
    registers to these default values.

 3. Confirm that the EGA Register Interface is present and if so,
    return its version number.

 If your program tries to set the EGA registers directly, rather than
 through the interface, the mouse cursor will draw incorrectly.


 17. No IBM DW4 or TopView Support for Bus Mouse with InPort

 Product Version(s): 6.00 6.02 6.10 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 21-APR-1988    ArticleIdent: Q28682

 Problem:
    IBM DisplayWrite 4 does not recognize the Bus mouse with Microsoft
 InPort Device Interface. DisplayWrite 4 supports the serial mouse and
 older Bus mouse (with a 8255 chip), but does not have an upgraded
 mouse driver for the InPort interface Bus mouse.
    This problem also occurs with IBM TopView.

 Response:
    Because DisplayWrite 4 has custom-made pointing device drivers, you
 should contact your IBM dealer or have the IBM dealer contact
 IBM dealer support.



 18. Mouse Compatibility with IBM PCjr

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified:  6-SEP-1988    ArticleIdent: Q29469

 The Microsoft Mouse has not been tested with the IBM PCjr. Microsoft's
 PCjr Booster, which was discontinued, was the only official hardware
 that included mouse support (i.e., bus mouse hardware).

 We have received customer reports stating that gray-button serial mice
 work properly on the PCjr if a special serial adapter is obtained to
 make the PCjr serial I/O compatible.

 We have not confirmed that Microsoft's new white-button mouse will
 work properly with the PCjr using the special adapter.

 Solid Rock was a company that provided PCjr accessories, but it has
 since gone out of business.


 19. Mouse MREADME.DOC: Single Drive PCs

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 29-JUN-1988    ArticleIdent: Q29702

    If you have a single-drive PC without a hard disk, you will not be
 able to use the Mouse Setup program (MSETUP) to set up the mouse
 software.
    MSETUP installs the mouse driver, MOUSE.COM.
    On a single-drive PC, you must install the mouse driver yourself in
 one of the following two ways:

    Manual Installation:      Copy MOUSE.COM onto the disk you use to
                              start your computer. You can then load
                              the mouse driver manually each time you
                              start your system, by typing "MOUSE" at
                              the DOS prompt.

    Automatic Installation:   With MOUSE.COM on the disk you use to
                              start your computer, you can modify your
                              AUTOEXEC.BAT file so that the mouse
                              driver is automatically loaded each time
                              you start your system. Add the line
                              "MOUSE" to the AUTOEXEC.BAT file to
                              automatically load MOUSE.COM when you
                              start your computer.

    For more information on this subject, see the "What the MSETUP
 Program Does" section of the "Microsoft Mouse User's Guide."


 20. Some ASCII Control Characters Incorrect in Programmer's Manual

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | mouse menu
 Last Modified: 31-AUG-1989    ArticleIdent: Q46923

 A documentation error on Page 2-24 of "Microsoft Mouse Programmer's
 Reference Guide" incorrectly states that ASCII value 28 corresponds to
 CTRL+\, not CTRL-. This error was corrected in "Microsoft Mouse
 Programmer's Reference" from Microsoft Press.

 Control characters CTRL+H, CTRL+I, CTRL+J, CTRL+M, and CTRL+[ are not
 listed in the table on Page 2-24 because their ASCII values are the
 same as ASCII codes for backspace, horizontal tab, linefeed, carriage
 return, and escape, respectively.


 21. Mouse MREADME.DOC: Invoking the Control Panel in Word

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 19-SEP-1988    ArticleIdent: Q29703

 Microsoft Word recognizes the CTRL+LEFT mouse button and SHIFT+LEFT
 mouse-button key combinations as Word operations.

 To invoke the Control Panel while working in Word, do the following:

 1. Hold down the CTRL key.
 2. Press the ALT or SHIFT keys before pressing the left mouse button.


 22. Mouse Driver Command Line Switches

 Product Version(s): 6.00 6.02 6.10 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 21-APR-1988    ArticleIdent: Q28684

    The following are command-line switches for mouse driver 6.00 and above:

    SWITCH       DESCRIPTION

    /B           Look for Bus or InPort mouse at primary address
    /I1          InPort mouse at primary address
    /I2          InPort mouse at secondary address
    /C1          Serial mouse on COM1
    /C2          Serial mouse on COM2
    /S <nnn>     Horizontal and vertical sensitivity <nnn> = 0 to 100
    /H <nnn>     Horizontal sensitivity
    /V <nnn>     Vertical sensitivity
    /R0          InPort interupt rate disabled
    /R1          InPort interupt rate 30Hz (default)
    /R2          InPort interupt rate 50Hz
    /R3          InPort interupt rate 100Hz
    /R4          InPort interupt rate 200Hz

    Example: mouse /s75    <- sets mouse sensitivity to 75 (50 default)



 23. Driver "Removed from Memory" Versus "Disabled"

 Product Version(s): 1.x 2.x 3.x 4.x 5.x 6.x
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 31-AUG-1989    ArticleIdent: Q47138

 MOUSE.COM Versions 6.00 and later are removed from memory unless
 connected to a PS/2 mouse port. The message "Existing Mouse Driver
 Disabled" appears if the mouse is connected to a PS/2 mouse port or if
 other terminate-and-stay-resident programs (TSRs) prevent the mouse
 from being removed from memory.

 Earlier versions of the mouse driver do not deallocate.

 Versions 6.11 and 6.12 are the only versions that are removed from
 memory if connected to the PS/2 mouse port.


 24. MREADME.DOC: Using the Default Expert Mouse Menu

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified:  5-JUN-1988    ArticleIdent: Q29705

    The default Expert Mouse menu allows you to use a mouse to emulate
 keys, such as the ESCAPE, ENTER, and cursor keys, with applications
 that normally do not support mice.

    To use this menu, load it into memory before you start your
 application.
    To load the default menu, type the following after the prompt of
 the drive or directory where the DEFAULT.COM file resides:

    default

    Once the default menu is loaded, you can perform the mouse actions
 described in the following tables to emulate certain keys in your
 application:

                  Press                     To Emulate

                  The left mouse button     The F3 key
                  The right mouse button    A carriage return (the ENTER key)
                  Both mouse buttons        The ESCAPE key

                  Move                      To emulate

                  The mouse to the left     The LEFT ARROW key
                  The mouse to the right    The RIGHT ARROW key
                  The mouse up              The UP ARROW key
                  The mouse down            The DOWN ARROW key

    To remove the default menu from memory, type the following after
 the prompt of the drive or directory where the DEFAULT.COM file
 resides:

                  default off



 25. Supplemental Mouse Menus Disk (Expert and Basic Menus)

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 14-JUL-1989    ArticleIdent: Q35131

 The following Microsoft Mouse menus are available by contacting the
 Microsoft Information Center by calling (800) 426-9400 and requesting
 the Mouse Supplemental Menus disk:

    Filename                 Application
    --------                 -----------

    MSMENU.COM               Most text-based software
    MSDB3.COM                dBASE III PLUS
    MS123.COM                Lotus 1-2-3, Versions 1A and later
    MSSYM.COM                Lotus Symphony, Versions 1.20 and 2.00
    MSMM2.COM                MultiMate Advantage II
    MSPF.COM                 PFS: Professional File, Version 2.00
    MSPLAN.COM               PFS: Professional Plan, Version 1.00
    MSPW1.COM                PFS: Professional Write, Version 1.00
    MSPW2.COM                PFS: Professional Write, Version 2.00
    MSSC4.COM                SuperCalc 4, Version 1.00
    MSWP4.COM                WordPerfect, Version 4.20
    MSWP5.COM                WordPerfect, Version 5.00
    MSWS.COM                 WordStar, Versions 3.30 and 4.00
    MSWS5.COM                WordStar, Version 5.00

 In addition, you will receive an Expert Mouse Menus disk with the
 following menus:

    Filename                  Application

    MS123-1.COM               Lotus 1-2-3 Version 1A
    MS123-2.COM               Lotus 1-2-3 Version 2
    MSDW.COM                  DisplayWrite 3 Version 1.10
    MSMM.COM                  MultiMate Version 3.31

 The expert menus have more functionality than the basic menus. The
 menus are sold for a small fee.


 26. Ventura Publisher 2.0 and Mouse Driver 6.24b

 Product Version(s): 1.x 2.x 3.x 4.x 5.x 6.x 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified:  6-JUL-1990    ArticleIdent: Q63224

 When mouse driver version 6.24b for the Microsoft Mouse is installed,
 Ventura Publisher version 2.0 is limited to black and white regardless
 of the screen colors selected.

 To correct this behavior, replace mouse driver 6.24b with mouse driver
 7.04.



 27. Mouse Versions Prior to New Mouse 1.00 Used MOUSE.SYS

 Product Version(s): 1.x 2.x 3.x 4.x 5.x 6.x
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified:  6-SEP-1988    ArticleIdent: Q35082

 Although there is no difference in functionality between the MOUSE.SYS
 and MOUSE.COM drivers, versions prior to the new white-button Version
 1.00 mice used MOUSE.SYS loaded from the CONFIG.SYS rather than the
 MOUSE.COM used via the AUTOEXEC.BAT file.

 The MOUSE.COM driver provides greater flexibility in that it is able
 to deallocate from memory and is executable from DOS.


 28. Mouse Menu May Have Up to 32 Menus

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified:  5-JUN-1988    ArticleIdent: Q29882

    There are 32 Menu statements allowed for each Mouse Menu. A
 combination of Popup and Menu statements can exceed 32.


 29. 123.MNU Worked on Floppy But Not on Hard Drive

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 19-SEP-1988    ArticleIdent: Q31045

 The Lotus 1-2-3 menu that was included with the original mouse (Word
 2.00 bundle) will not work if Lotus 1-2-3 was loaded from the hard
 disk and you have the bus mouse set for interrupt 5 on your IBM PC.
 The menu runs properly from a floppy.

 Change the interrupt setting to 2 on the bus card to resolve this
 problem.


 30. Windows Versions 1.01 and 1.02 and the Bus Mouse

 Product Version(s): 3.00
 Operating System:   MS-DOS
 Flags: ENDUSER | TAR59473
 Last Modified:  4-NOV-1988    ArticleIdent: Q19915

 Windows Versions 1.01 and 1.02 will hang or will not recognize bus
 mouse Version 5.03 (InPort hardware) or later.

 Windows Versions 1.01 and 1.02 contain an initial release of
 MOUSE.DRV. Beginning with Version 5.03 of the bus mouse, new InPort
 hardware was incorporated in the bus mouse design. An update to the
 MOUSE.DRV software is required for Windows to correctly recognize the
 mouse.

 The updated MOUSE.DRV is included in Windows Version 1.03 and later.
 In addition, it is included in the mouse Version 5.03 System disk and
 the current mouse Version 1.00 Setup disk.

 If you have Version 6.x of the mouse, you can obtain the updated
 MOUSE.DRV by calling Microsoft Product Support hardware group at (206)
 454-2030 and requesting for the "Mouse Drivers Update Disk."

 The above problem may also affect ISVs and OEMs that have developed
 stand-alone Windows applications or have licensed and adapted Windows
 using the initial Windows development software.


 31. Mouse-Cursor State and EGA Memory

 Product Version(s): 6.x
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 28-JUN-1988    ArticleIdent: Q31149

    The Microsoft Mouse driver EGA interface maintains the mouse-cursor
 state in the unused 8K of video memory available at the top of the
 four 64K buffers that comprise the 256K of total video memory
 available on a loaded EGA adapter. Normally this is of little
 consequence in programming such systems; however, if you resize the
 video buffer by reprogramming the CRT Controller's Offset register,
 problems may occur.
    You will know there is a problem if garbage appears on the display
 after panning through an enlarged virtual screen.
    To work around this problem, do not use Mouse Function 1 to show
 the mouse cursor. Instead, use an alternative method of monitoring the
 mouse's screen location (e.g. XOR some graphical object to the
 screen).


 32. CPANEL May Crash if /S Switch Used Previously

 Product Version(s): 6.x 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 19-SEP-1988    ArticleIdent: Q35229

 If a value such as /s33 is passed to the mouse driver before invoking
 CPANEL, CPANEL may crash if you keep decrementing while in the CPANEL
 screen. The CPANEL will not be invoked and a divide overflow may
 occur, but the mouse driver remains intact.


 33. Using Mouse Menus with WordPerfect Version 5.00

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 28-JUN-1988    ArticleIdent: Q31293

    When using a Mouse menu with WordPerfect Version 5.00, the menu
 opens; however, no text appears at the current cursor location when a
 selection is made. Upon exiting WordPerfect, the characters from the
 menu appear at the DOS command prompt.
    WordPerfect Version 5.00 has keyboard macros that disable the Mouse
 menu while in WordPerfect. To use a Mouse menu with WordPerfect
 Version 5.00, you must start WordPerfect with the /nk switch. This
 will disable the keyboard macros and allow the Mouse menu to function
 normally.


 34. Mouse Driver Conflict with Fixed-Disk Organizer

 Product Version(s): 6.x
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 25-JUL-1988    ArticleIdent: Q31330

    The mouse driver may not install due to a possible conflict between
 the Microsoft Mouse driver and the IBM fixed-disk organizer (FDO).
    This problem can be avoided by altering the load order of the two
 programs. If the mouse driver is loading first and being destroyed by
 the FDO, edit your AUTOEXEC.BAT file so the FDO loads first. If the
 FDO is loading first, load it after the mouse driver.
    Please note that this workaround is not guaranteed to avert all
 conflicts, but it has yielded positive results in many instances.


 35. "Microsoft Mouse Driver Not Found" Error Message

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 19-JUL-1988    ArticleIdent: Q32263

    The MOUSE.COM or MOUSE.SYS driver must be loaded before attempting
 to load a mouse menu. The "Microsoft Mouse driver not found" error
 message is generated when a mouse expert menu tries to load without
 the mouse driver already loaded.
    This error message should not be confused with the message "Driver
 not installed-- Microsoft Mouse not found", which is a mouse driver
 not loading message.


 36. CPANEL Defaults to Display Page 0

 Product Version(s): 6.x 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 19-SEP-1988    ArticleIdent: Q35230

 CPANEL may not display in a graphics application that uses graphics
 pages greater than 0. CPANEL defaults to display on Page 0 of the
 graphics page.

 To work around this problem, use the /S switch to the mouse driver.


 37. /S1 or /S2 Yields Same Result as /S0

 Product Version(s): 6.x 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 19-SEP-1988    ArticleIdent: Q35231

 If a sensitivity switch of value 1 or 2 is passed to the mouse driver,
 you may not recognize any mouse cursor change for mouse movement. A
 sensitivity value of 3 seems to be the minimum sensitivity that the
 mouse driver moves the cursor.


 38. Internal Processing Error and OS2MOUSE.V12 with Mouse

 Product Version(s): 1.20
 Operating System:   OS/2
 Flags: ENDUSER |
 Last Modified:  6-JUL-1990    ArticleIdent: Q63226

 When OS2MOUSE.V12 is installed and the communications manager is
 selected, an internal processing error is detected and the system will
 hang.

 To correct this problem, reinstall the mouse driver using the drivers
 that were supplied with the OS/2 package and the system will not hang
 when the communications package is selected.

 We are researching this problem and will post new information here as
 it becomes available.


 39. Symphony Mouse Menu Works in Text Mode Only

 Product Version(s): 1.0
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 21-APR-1988    ArticleIdent: Q28425

    When using the Symphony mouse menu, please make sure Symphony is
 set up for "text and graphics separate".

    If you are running Symphony with an EGA, Symphony comes up in green
 for "text and graphics separate" configurations. Combined
 configuration will display in red when Symphony is running.


 40. Standard Mouse Menus Do Not Deallocate

 Product Version(s): 4.x 5.x 6.00
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 29-AUG-1988    ArticleIdent: Q23827

 You cannot deallocate a standard mouse menu (a menu that loads with
 MENU.COM) from memory. Entering "menu off" will disable the keyboard
 emulation; however, it will not deallocate from memory.


 41. Available Mouse Menus

 Product Version(s): 4.x 5.x 6.x
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 23-AUG-1988    ArticleIdent: Q23836

    Version 6.00 of the Microsoft Mouse contains "Expert Mouse Menus"
 for Lotus 1-2-3 Versions 1A and 2.00, MultiMate Version 3.31, and
 DisplayWrite 3 Version 1.10. The "Mouse Programmer's Reference Guide"
 contains "Standard Mouse Menus" for previous versions (date mid-1985)
 of Symphony, WordStar, Multiplan, and VisiCalc.


 42. Expert and Standard Mouse Menus

 Product Version(s): 4.x 5.x 6.00
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 23-AUG-1988    ArticleIdent: Q23837

 Question:
    What is the difference between an Expert and a Standard mouse menu?

 Response:
    Standard mouse menus are loaded with MENU.COM, while an Expert
 mouse menu is an executable .COM file.


 43. CPANEL Does Not Display in the OS/2 DOS 3.x Box

 Product Version(s): 6.x 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 19-SEP-1988    ArticleIdent: Q35232

 CPANEL will not work in the OS/2 DOS 3.x box unless you load the DOS
 mouse driver rather than the OS/2 mouse driver.


 44. MSETUP Installs on Drive Specified

 Product Version(s): 6.x 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 19-SEP-1988    ArticleIdent: Q35250

 If you have more than one hard-disk partition, MSETUP has the
 capability of installing the mouse software on a partition that may
 not be your C: drive. If you select to do this, you must manually edit your
 AUTOEXEC.BAT file to invoke the mouse driver and optionally CPANEL.
 For example, to install the mouse software on your D: drive, you must
 edit your AUTOEXEC.BAT on your boot drive C: to the following:

 D:\mouse1\mouse
 D:\mouse1\cpanel



 45. Standard Mouse Menus Are Not in .COM Format

 Product Version(s): 6.00
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 23-AUG-1988    ArticleIdent: Q23829

    You cannot write menus in .COM format with the "Mouse
 Programmer's Reference Guide." The reference guide allows you to
 create standard mouse menus, which are installed with the MENU.COM
 file.
    If you are a developer interested in creating menus in .COM format,
 an Expert Menus Toolkit is available that allows you to create expert
 mouse menus. For more information, call Microsoft Hardware Development
 at (206) 882-8080, and ask for information on Expert Menus Development
 software.


 46. Earlier Versions with Mouse Menu Software

 Product Version(s): 4.x 5.x 6.00
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 23-AUG-1988    ArticleIdent: Q24163

    The content of the "Microsoft Mouse Programmer's Reference Guide"
 is similar to earlier versions of the mouse containing the mouse
 programming.
    If you are writing standard mouse menus, the commands in the
 "Microsoft Mouse Programmer's Reference Guide" are the same as they
 were with versions prior to Version 6.00. The major changes include
 better documentation, examples, and updated mouse libraries. If you
 have a version prior to Version 5.03, we recommend that you obtain the
 "Microsoft Mouse Programmer's Reference Guide" if you are having any
 problems with MENU.COM or MAKEMENU.EXE.


 47. Applications That Do Not Use the Mouse

 Product Version(s): 4.x 5.x 6.00
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 29-AUG-1988    ArticleIdent: Q24164

 The "Microsoft Mouse Programmer's Reference Guide" allows you to write
 your own mouse menus for programs without mouse support. The reference
 guide includes the necessary software and documentation to provide
 keyboard emulation using mouse menus. Mouse menus will run in text
 mode with most programs that do not grab the keyboard interrupts.


 48. MENU.COM Needed to Load .MNU Files

 Product Version(s): 4.x 5.x 6.00
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 29-AUG-1988    ArticleIdent: Q24178

 With the release of Version 6.00 of the mouse, we decided to separate
 the programming aspects of the mouse and place them in the "Microsoft
 Mouse Programmer's Reference Guide." The guide contains the menu
 installer MENU.COM and the menu compiler MAKEMENU.EXE. If you have the
 software prior to Version 6.00, you will find MENU.COM and
 MAKEMENU.EXE on your system diskette.



 49. Mouse Menus May Hang in the OS/2 DOS 3.x Box

 Product Version(s): 6.x 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 19-SEP-1988    ArticleIdent: Q35251

 Mouse menus may hang in the OS/2 DOS 3.x box if you are using the OS/2
 mouse drivers. To work around this problem, use the DOS mouse drivers
 that were included with your mouse and do not load the OS/2 mouse
 driver.


 50. Menu Problems with Leading Edge D2 in 43-Line Mode

 Product Version(s): 1.0
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 21-APR-1988    ArticleIdent: Q28428

    The characters on the screen get trashed if you load a mouse menu
 in 43-line text mode using a Leading Edge D2 with monochrome display.
 The characters are readable, but the top two or three lines of pixels
 composing the characters are repeated beneath the characters (similar
 to a vertical ghost effect).

    Resetting the EGA into the 43-line mode corrects the problem
 temporarily. Run EGA.EXE with the argument EGA, or set switch 5 on the
 display adapter to the open position to disable the auto-mode
 selection feature (this process produces the same effect as the EGA
 EGA command).


 51. Erratic Cursor Movement Using 123 Mouse Menu

 Product Version(s): 4.x 5.00
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified:  4-NOV-1988    ArticleIdent: Q24710

 If the cursor moves erratically when using the 123.MNU mouse menu
 provided with Version 5.00 of the mouse, make sure no other
 memory-resident programs are interfering. If the problems persist,
 contact Microsoft Product Support at (206) 454-2030 for the 123 Menu
 disk, which includes an updated 123.MNU file.

 If you own Mouse Version 6.00, use the MS123-2.COM found on your
 Expert Mouse Menus disk. This supersedes the 123.MNU file.


 52. Operation of InPort Chip Versions 1.00 and 1.10 Versus 1.20

 Product Version(s): 1.00 1.10 1.20
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 19-MAR-1990    ArticleIdent: Q49003

 Versions 1.00 and 1.10 of the Microsoft Mouse InPort Chip operates in
 the timer interrupt mode (mouse service routine interrupt occurs at a
 fixed rate).

 Version 1.20 of the InPort Chip operates in the data interrupt mode
 (mouse service routine interrupt occurs whenever mouse data is
 present).


 53. Bus Mouse with InPort Not Supported in IBM PC-DOS 4.00

 Product Version(s): 6.x 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 19-SEP-1988    ArticleIdent: Q35364

 IBM PC-DOS Version 4.00 has three special mouse drivers that only work
 with the DOS Shell: PS/2, serial, and bus mouse (non-InPort).

 For bus mice with InPort, we recommend that you load the mouse driver
 that was included with your mouse (MOUSE.COM) and delete the following
 command line in the DOSSHELL.BAT that loads the IBM DOS shell mouse
 driver:

 /MOS:PCMSPDRV.MOS


 54. Unable to Activate the Mouse in Chart

 Product Version(s): 6.00
 Operating System:   MS-DOS
 Flags: ENDUSER | TAR64094
 Last Modified: 19-SEP-1988    ArticleIdent: Q25053

 You may be unable to activate the mouse in Chart; the mouse arrow may
 appear to be frozen.

 Chart defaults serial printer drivers to COM1:. Therefore, when using
 a serial mouse, it is necessary to start Chart and then change the
 Print Setup adapter in the Chart screen to something other than the
 COM port to which the mouse is connected. You must do the following to
 activate the mouse:

 1. Change the Print Setup adapter in the Chart screen from COM1: to
    LPT1:.

 2. Exit.

 3. Restart Chart.


 55. End User Made Mouse Menus Don't Run Under MS-DOS 4.00 or 4.01

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 20-JUN-1990    ArticleIdent: Q61105

 Mouse menus compiled with MAKEMENU.EXE and run with the MENU.COM that
 came with Mouse driver versions 6.24b and earlier will not work under
 MS-DOS version 4.00 or 4.01. The menu will install into memory, but
 will not be visible and will not interface correctly with the
 application.

 Currently, the only workaround is to load the ANSI.SYS driver with the
 /k option. This disables the extended keys on the keyboard, which
 allows your Mouse menus to work.

 Microsoft is researching this problem and will post new information
 as it comes available.


 56. Using PS/2 Serial Mice with Laptop Computers

 Product Version(s): 1.0
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 14-JUL-1989    ArticleIdent: Q28492

    Microsoft PS/2 serial mice are not guaranteed to work correctly
 with laptops due to the low power specification on serial ports
 usually found on the laptops.

    PS/2 serial mice with the SSMA adapters (cigarette box shaped
 adapters) may not work properly with the Zenith laptop models 181 and
 183.
    The current mice with the UMA adapters (cigar-shaped adapters) with
 the Version 6.14 mouse driver have been tested informally and seem to
 work properly with the Zenith laptops.


 57. Restricted Mouse Cursor Movement in Pro Design II

 Product Version(s): 1.0
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 21-APR-1988    ArticleIdent: Q28493

    When using Pro Design II, the mouse cursor is restricted to a 1
 inch box in the top left-hand corner.

    This problem has been reported with the mouse driver Version 6.02 through
 mouse driver Version 6.11. Currently the problem cannot be isolated to a
 mouse driver problem since the cursor movement restriction seems to occur
 only with the Pro Design II application.
    Please contact American Small Business Computers, developers of Pro
 Design II, at (918) 825-4844. An update may resolve the problem.
    Microsoft is researching this problem and will post new information
 as it becomes available.


 58. NEC Multispeed Laptop Continues to Access Drive

 Product Version(s): 6.0 6.02 6.10 1.0
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 21-APR-1988    ArticleIdent: Q28494

    When using the NEC Multispeed laptop with the mouse driver
 installed, the disk light stays on as if the disk is being accessed.

    NEC produced a patch INIT059.COM or ROM upgrade that resolves the
 problem.
    Please contact NEC's technical support at (800) 632-7368.


 59. Tests with the Compaq 386/20

 Product Version(s): 1.0
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 21-APR-1988    ArticleIdent: Q28495

    The new Bus and PS/2 serial mice work properly with the Compaq
 386/20 computer.

    The Version 1.0 mouse and revision G of the Bus interface board
 worked properly with the Compaq 386/20 with the Version 6.11 of the
 mouse driver.
    The white button and gray button serial mice tested successfully
 with the Compaq 386/20's serial port.


 60. FCC Class B Approval

 Product Version(s): 1.0
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 21-APR-1988    ArticleIdent: Q28496

    The new Version 1.0 mice have Class B FCC approvals.

    The InPort mouse and the InPort interface card of the new white
 button Version 1.0 mice have FCC Class B approvals (ID C3K7PN9937 for
 the mouse and C3K6P8 for the interface card respectively).


 61. Interrupt Setting for the IBM PS/2 Model 30

 Product Version(s): 1.0
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 21-APR-1988    ArticleIdent: Q28497

    When setting the J4 interrupt setting on the mouse InPort interface
 card, Microsoft recommends jumper 2 or 3.

    Please check that other peripheral boards are not using the same
 interrupt setting as the mouse. Do not use pair 5 for the setting.


 62. Installing Windows when Using the PS/2 Mouse Port

 Product Version(s): 6.10 1.0
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 21-APR-1988    ArticleIdent: Q28498

    If you are using the IBM PS/2 mouse port for your mouse, please be
 sure to select IBM PS/2 when selecting a pointing device during the
 Windows Version 1.04 installation.

    Selecting the Microsoft mouse when using the IBM PS/2 mouse port
 will not give you mouse control in Windows Version 1.04.


 63. DOS 2.xx Does Not Recognize \Mouse1\Mouse

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 26-APR-1988    ArticleIdent: Q28499

 Problem:
    After running the mouse setup routine and rebooting my machine, the
 mouse driver will not install.

 Response:
    Because DOS Version 2.xx does not recognize the path statement in
 command lines, such as /mouse1/mouse in the AUTOEXEC.BAT file, the
 mouse driver never installs.
    To work around this, edit your AUTOEXEC.BAT file to change the
 directory to your MOUSE1 subdirectory. Then, directly call the MOUSE
 and CPANEL as follows:

   CD \MOUSE1
   MOUSE
   CPANEL
   CD\


 64. Use MOUSE.SYS with Flight Simulator

 Product Version(s): 1.0
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 21-APR-1988    ArticleIdent: Q28500

    If you have Flight Simulator and a mouse, you should use the
 MOUSE.SYS file in the CONFIG.SYS file rather than the MOUSE.COM in the
 AUTOEXEC.BAT file that is installed by the mouse setup.

    The Version 6.11 of the mouse driver that uses the MOUSE.COM file,
 may cause Flight Simulator to continuously ask if you have a mouse.
 Using the MOUSE.SYS file solved the problem.


 65. Windows 1.01 MOUSE.DRV File Included with Mouse 1.0

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 21-APR-1988    ArticleIdent: Q28502

    The current Mouse Setup disk contained in the EasyCad and MS
 Paintbrush software includes the mouse driver for Windows Version 1.01
 owners.

    Because the Windows Version 1.01 mouse driver does not recognize
 mice with InPort hardware, Microsoft has included an updated MOUSE.DRV
 file to resolve the problem.
    Copy the MOUSE.DRV file to your Windows Install disk and reinstall
 the Windows software. If you have Windows Version 1.03 or a newer
 version, you will not have this problem.


 66. Compaq Portable 3 Compatibility

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified:  6-SEP-1988    ArticleIdent: Q28503

 The Compaq Portable 3 has built-in hardware that includes a serial
 port and an expansion chassis slot. The serial mouse should work
 properly in the standard serial port. The bus mouse will not fit in
 the only slot available for the expansion chassis, but should fit in
 the expansion chassis slot (this has not been tested).


 67. STB VGA Extra Using Mouse

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 19-SEP-1988    ArticleIdent: Q28504

 STB requests that callers having problems with the mouse and VGA Extra
 (unspecified symptoms) contact STB at (214) 234-8750.


 68. Mouse Installation with OS/2

 Product Version(s): 1.0
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 21-APR-1988    ArticleIdent: Q28505

    OS/2 does not use the mouse driver contained with the Microsoft
 mouse.

    The DOS mouse driver MOUSE.COM or MOUSE.SYS does not load if you
 install OS/2 on a machine unless you have a dual boot option where
 standard DOS is loaded. OS/2 has a custom driver MOUSExxx.SYS which
 will run in the OS/2 protected mode or DOS compatibility box. In
 addition to the OS/2 mouse driver, you should load the POINTDD.SYS and
 EGA.SYS as well. Refer to your OS/2 documentation for further OS/2
 mouse driver details.


 69. Cipher Data Tape Drive Conflicts with Bus Mouse

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified:  6-SEP-1988    ArticleIdent: Q28515

    The Cipher Data Tape Drive can be set to use I/O address 220-23F;
 however, this setting causes the drive to forward and reverse every
 time the Bus mouse moves.
    The Tape Drive can reportedly use another I/O address to resolve
 the conflict. This is not a problem with the serial mouse.


 70. Choice of Three Software Bundles for New Mouse 1.00

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 31-AUG-1989    ArticleIdent: Q28517

 The new white-button mice are available in three software bundles. You
 can purchase a PS/2 serial or bus mouse with one of the following
 products:

 1. EasyCAD

 2. Microsoft Paintbrush with Mouse Menus

 3. Windows with Paintbrush for Windows


 71. Bus Mouse Jumper Settings J2, J3, and J4

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified:  5-JUN-1988    ArticleIdent: Q28538

    The new white-button Bus Mouse Version 1.00 interface card
 (Revision G) is an InPort interface half-size card. When installing
 the interface card, the jumper settings J2, J3, and J4 must be
 correctly set for the mouse to function properly.

    The J2 jumper setting allows you to use your Bus mouse from slot 8
 if you have an IBM PC XT. Set the top two pins to the "XT SLOT 8"
 configuration. If you have an IBM PC, AT, or some other non-IBM PC XT,
 you can leave the jumper setting on the "Normal" position (the lower
 two settings).
    The J3 jumper setting allows you to set another I/O address space
 other than the default 23C-23F. The "Primary" settings are the top two
 settings, while the "Secondary," which has the I/O address 238-23C, is
 the bottom two settings.
    Microsoft recommends that you only change this setting if another
 InPort interface hardware item is used in your system or if another
 system peripheral card is using the same I/O addresses.
    The J4 jumper setting allows you to select an IRQ or machine
 interrupt. Microsoft recommends that you select an interrupt from two
 through five that is not used in your system. In most instances,
 although you should confirm that another card is not using the same
 interrupt, an IBM PC or XT has interrupt two available for you to use
 and an IBM PC AT usually has interrupt five available.
    Refer to Page 6 of your "Microsoft Mouse User's Guide" for more
 information.


 72. Mouse and Flight Simulator 3

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 25-JUL-1988    ArticleIdent: Q32028

    Mouse driver Versions 6.02, 6.11, 6.14, and 6.23 have been tested
 with Flight Simulator 3 and all work normally.


 73. Mouse, Windows, Desqview, and HP Drawing Gallery

 Product Version(s): 6.00 6.10 6.14
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 25-JUL-1988    ArticleIdent: Q32064

    If you run Hewlett-Packard Drawing Gallery from either Windows or
 Desqview and exit the program normally, the mouse still works
 correctly; however, there is no cursor.
    To correct this problem, modify the PIF file included with the
 program. Under the Directly Modifies section, select Memory in
 addition to Screen.


 74. Earlier Versions of Generic Cad May Not Work with InPort

 Product Version(s): 1.00 5.03 6.00 6.02 6.10
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified:  8-AUG-1988    ArticleIdent: Q32129

    Generic Cad recommends Interrupt 3 for the J4 setting of the bus
 mouse.
    Be aware that older versions (possibly releases 1 and 2) of Generic
 Cad may not work correctly with versions of the bus mice that include
 the InPort Interface. Because Generic Cad goes directly to the
 hardware (i.e., it uses its own mouse driver), you must obtain an
 update to release 1 or 2. To obtain an update, contact Generic Cad by
 calling (206) 487-2934.


 75. Mouse Must be Removed to Run PS/2 Diagnostics

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 13-FEB-1989    ArticleIdent: Q33570

    When running the PS/2 diagnostics program with a Microsoft Mouse on
 the mouse port, the mouse must be disconnected. If the mouse is not
 disconnected the machine will hang.


 76. Sensitivity May Reset if a /R Switch Passed to the Driver

 Product Version(s): 6.24
 Operating System:   MS-DOS
 Flags: ENDUSER |  buglist6.24
 Last Modified: 11-OCT-1988    ArticleIdent: Q35974

 If an /R switch is passed to the MOUSE.COM, the sensitivity may reset.
 Note: the /R switch is only used with the Bus Mouse with InPort
 hardware.

 Microsoft has confirmed this to be a problem in Version 6.24. We are
 researching this problem and will post new information as it becomes
 available.


 77. Extension Cables for Microsoft Mice

 Product Version(s): 5.x 6.x 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 17-JUL-1989    ArticleIdent: Q32128

 Microsoft retails a 1.5-meter InPort extension cable. Although the
 cable was designed for the gray-button mouse, we have found, under
 informal testing, that the extension cable works with the new
 white-button mice (serial and bus).

 If you decide to make a longer cable, special wire is not needed. The
 Microsoft extension cable uses shielded, 7-conductor, 30-gauge wire. A
 heavier gauge wire might be considered for strength.

 If an extension is added to the serial mouse, the cable needs to pass
 the following pins straight through as follows:

    pins 2,3,4,7,20 and shield for the 25-pin D version, or
    pins 2,3,4,5,7 and shield if using the 9-pin version.

 Microsoft is not aware of any special considerations for special
 installation, such as alignment to compensate for cable
 characteristics, special cable termination (R, RC, etc.), needed for
 line drivers, or noise-immunity considerations.

 If you do anything to change the mouse cabling, the machine is likely
 to violate FCC Electromagnetic Interference regulations. The computer
 may interfere with nearby television or radio reception. Operation in
 a residential environment is especially ill-advised, and such a
 configuration certainly cannot be offered for sale without extensive
 testing and FCC certification.

 Microsoft takes no responsibility for the performance of its products
 when modified or used in a manner other than that intended and advised
 in the manual. Microsoft assumes the customer will comply with all
 applicable laws and regulations, and offers the above advice only on
 that basis.


 78. AT&T 6300 Plus and Bus Mouse

 Product Version(s): 5.00 5.30 6.00 6.10 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 19-JUL-1988    ArticleIdent: Q32682

    When using the bus mouse with the AT&T 6300 Plus, the J4 jumper
 must be set to either 3 or 4.
    There have been problems reported while using interrupt 5 with this
 computer; this should be a free interrupt on an AT machine. This
 problem may occur with any program that uses the mouse; however, the
 problem has not occurred with Paintbrush, CPANEL.COM, and DEFAULT.COM.


 79. DEFAULT.COM Included with Mouse

 Product Version(s): 1.x 2.x 3.x 4.x 5.x 6.x 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 19-JUL-1988    ArticleIdent: Q32714

    If you have the new white-button mouse Version 1.00, the
 DEFAULT.COM file, which provides cursor emulation, is located on the
 Mouse Setup Disk. Version 6.00 through 6.10 owners have the
 DEFAULT.COM file located on their Mouse Expert Menus Disk. Mouse
 owners with versions prior to Version 6.00 can write their own menus
 using the mouse menu programming tools (MAKEMENU.EXE and MENU.COM)
 included with their mouse software.


 80. Resolution, Mickeys, or Points Per Inch of the Mouse

 Product Version(s): 1.x 2.x 3.x 4.x 5.x 6.x 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified:  4-AUG-1988    ArticleIdent: Q33066

    The resolution (or mickeys) of Versions 5.x and 6.x of the mouse
 (gray buttons), and the new Version 1.00 of the mouse (white buttons)
 is 200 ppi. For example, the mouse driver can recognize 1/200th of an
 inch movement of the mouse. The resolution of Versions 1.x, 2.x, 3.x,
 and 4.x of the mouse (green buttons) is 100 ppi.


 81. PS/2 Mouse on Mouse Port Initializes Slowly

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified:  2-AUG-1988    ArticleIdent: Q33106

    If you load a program when using a serial PS/2 mouse on the PS/2
 mouse port, it will take longer to load than a serial or bus connect
 because the mouse initialization is performed through the PS/2 BIOS.


 82. Mouse and IBM Page Printer Hang System

 Product Version(s): 6.x 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified:  4-AUG-1988    ArticleIdent: Q33117

    When using the Microsoft Mouse with an IBM Page Printer, the mouse
 driver must use MOUSE.SYS rather than MOUSE.COM. To use the mouse with
 an IBM Page Printer, do the following:

    1. Copy MOUSE.SYS from the Setup/Basic Menus disk to the MOUSE1
       subdirectory of your hard drive.
    2. Edit your AUTOEXEC.BAT file (found in the root directory) and
       remove the following line:

       /MOUSE1/MOUSE

    3. Edit your CONFIG.SYS file (also found in the root directory) and
       insert the following line prior to the line that loads the Page
       Printer driver:

       DEVICE=C:\MOUSE1\MOUSE.SYS

    4. Reboot the machine. The mouse now can be used in conjunction
       with the Page Printer.


 83. Tempest-Approved Mouse

 Product Version(s): 6.00   | 6.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified: 31-AUG-1989    ArticleIdent: Q47676

 Tempest versions of the Microsoft Mouse are available from Quality
 Tempest Products (QTP) of Herndon, Va.

 A Tempest "approved" mouse is one that has been modified so that there
 are no RF emissions. This modification is needed so the mouse can be
 used in sensitive or classified areas

 For more information, contact Steve Rice of QTP at (703) 834-5200.


 84. Jumper Settings for Bus Mouse Used in an XT 286

 Product Version(s): 1.x 2.x 3.x 4.x 5.x 6.x 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 23-AUG-1988    ArticleIdent: Q34009

    For the purpose of setting the jumpers on the bus mouse card, the
 IBM XT 286 is equivalent to an IBM AT. The hard disk in the IBM XT 286
 uses IRQ 2. The typical settings are as follows:

    Jumper    Setting
      J2      normal
      J3      primary
      J4      IRQ 5

    As always, be sure that IRQ 5 is not being used for other hardware
 devices, such as a Bernoulli box, network card, or tape backup.


 85. Mouse and AutoCAD

 Product Version(s): 1.x 2.x 3.x 4.x 5.x 6.x
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 19-SEP-1988    ArticleIdent: Q33476

 AutoCAD contains its own mouse driver; therefore, it does not need to
 have the Microsoft Mouse Driver installed to take advantage of the
 Microsoft Mouse. If the Microsoft Mouse Driver is installed, it may
 cause a TSR-type error when AutoCAD is run.

 AutoCAD problems can be directed to Autodesk by calling (415)
 332-2344.


 86. Cursor Freezes when Using Old Mouse Driver on AT-Type Machine

 Product Version(s): 5.03
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified:  8-AUG-1988    ArticleIdent: Q33553

    The mouse cursor may freeze or leave contrails in application
 programs running on 80286 or 80386-based machines if the mouse driver
 is Version 5.03 or earlier.
    The keyboard ordinarily will still work correctly. You should
 update to the current version of the driver.


 87. Mouse Menu for Quattro

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 17-MAY-1989    ArticleIdent: Q34086

 The Lotus 1-2-3 mouse menus on the Mouse Expert Menus disk do not
 enable the pop-up menus in Quattro. To use the mouse with Quattro,
 install DEFAULT.COM or MSMENU.COM.

 MSMENU.COM allows you to scroll through the spreadsheet and select
 menu items with the mouse. The menus do, however, need to be activated
 with the SLASH (/) key. The menus function the same whether or not
 Quattro is loaded with the Lotus 1-2-3 menu tree.

 Note: DEFAULT.COM is now called MSMENU.COM.


 88. Selecting Communications Ports, Interrupts in COMPAQ SLT/286

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | mouse
 Last Modified: 19-MAR-1990    ArticleIdent: Q48414

 On a COMPAQ SLT/286, the communications port and its associated
 interrupt can be set by using the Setup/Diagnostic program included
 with the computer. The following is the procedure:

 1. Place the Setup disk in your floppy drive.

 2. Run the Setup program.

 3. At the menu screen, press F4 to select "change configuration."

 4. From the next menu screen, select "Modem async-device."

 5. From the next screen, select "system async device."

 6. From the next screen, select "com1."

 7. From the next screen, select "interrupt 4."

 8. Back up through the screens until you return to the DOS prompt.


 89. Text Mode Problem with Mouse Version 3.00

 Product Version(s): 3.00
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist3.00 fixlist4.00
 Last Modified: 11-OCT-1988    ArticleIdent: Q11085

 Question:

 Were there any known problems with Hercules graphics support with the
 mouse Version 3.00? When we use the routine reccommended by Hercules
 to get the mouse into graphics mode, we still get a text mouse when we
 use function 0 of the mouse library.

 Response:

 There is a problem in the mouse driver that is defaulting the text
 cursor to the hardware text cursor, instead of to the software text
 cursor. Microsoft has confirmed this to be a problem in Version 3.00.
 This problem was corrected in Version 4.00.

 There are two possible solutions for the problem: use only driver
 Version 4.00 or later, or insert a mouse function 10 call (Set Text
 Cursor) into the beginning of the application program, with the second
 parameter (M2%) set to 0 (select software text cursor).


 90. Losing Data When Mouse and Data Transfer Are Involved

 Product Version(s): 6.00 6.11 6.14 6.24 6.24b
 Operating System:   DOS
 Flags: ENDUSER |
 Last Modified: 22-MAR-1990    ArticleIdent: Q49285

 Several customers report lost data or a system lock up when
 transferring high speed data from a modem or mainframe through a
 serial port. The mouse was resident in memory when the problem
 occurred.

 With communications going through COM2:, the interrupt 3 is in use.
 This interrupt has a higher priority than either interrupt 4 (for a
 mouse in COM1:) or interrupt 5 (bus mouse with interrupt 5 set on the
 J4 jumper).

 You should ensure that the communications equipment is loaded onto
 COM2: so that it can take advantage of the higher priority interrupt.
 The phenomenon is inherent with interrupt handling and established
 priorities.


 91. Intermittent Installation on the Packard-Bell PS/2 Port

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified:  8-MAY-1990    ArticleIdent: Q61591

 When the 400 dpi Microsoft Mouse is attached to the PS/2 port of the
 Packard-Bell PackMate 2, the Excel 5, and the Legend 5 computers, the
 mouse sometimes does not install correctly.

 When the mouse is attached to the serial port there are no
 installation problems.

 If you are experiencing this problem, contact Packard-Bell at
 (818) 773-4400.


 92. Sluggish or Jerky Mouse Motion in PC DOS Version 4.00 Shell

 Product Version(s): 4.00
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 11-OCT-1988    ArticleIdent: Q35975

 When using the IBM PC DOS Version 4.00 shell mouse drivers with an IBM
 PS/2, the mouse motion may appear sluggish or jerky.

 To work around this problem, do not load the PC DOS Version 4.00 mouse
 drivers /MOS:PC??DRV.COM (where ?? is PC or MS) and load the Microsoft
 mouse driver MOUSE.COM before running the DOSSHELL.BAT file.


 93. Deallocating Memory When Using Compaq and IBM Mouse Ports

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 31-AUG-1989    ArticleIdent: Q43344

 When using a PS/2 style mouse port, you cannot deallocate the memory
 the mouse driver is using. The Mouse Off switch disables only the
 mouse. However, the memory will be deallocated if a bus or serial
 mouse is used.

 The following machines have PS/2 style mouse ports:

 1. COMPAQ 286e, 386s, 386e, and 386 20e

 2. IBM (all PS/2's)


 94. Mouse Will Not Work with PC Tools Deluxe 5.5 and 6.0

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 14-MAY-1990    ArticleIdent: Q61264

 If PC Tools Deluxe versions 5.5 and 6.0 are loaded as memory resident,
 the mouse cursor may or may not be displayed on the screen. If the
 mouse cursor is displayed, it will not move.

 This problem has been corrected in a later version of PC Tools.

 For information about this update, contact Central Point Software at
 (503) 690-8080.


 95. "Mouse Off" Hangs System: Samsung AT Compatible with J4 on 2

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified:  1-NOV-1988    ArticleIdent: Q37252

 On the Samsung S-500 AT compatible, typing "Mouse Off" may hang the
 system if the Bus mouse J4 jumper is set on interrupt 2. Moving the
 jumper to interrupt 5 eliminates the problem.


 96. Excellerator Requires Ms-DOS Version 3.30 with AT&T 6312

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 10-JAN-1989    ArticleIdent: Q37254

 When using the Excellerator (a code generation program) with an AT&T
 6312, MS-DOS Version 3.30 must be used.

 When any version of DOS earlier than Version 3.30 is used with the
 AT&T 6312 machine and the Excellerator, one of the following symptoms
 may occur:

 1. More than one cursor may appear.

 2. The mouse pointer may skip pixels as it is moved across the screen.

 3. Hieroglyphics may appear.

 According to Leading Index, the problem can be corrected by upgrading
 to MS-DOS Version 3.30.


 97. Mouse Command-Line Switches for Mouse Driver Version 7.04

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | Video 7 Video-7
 Last Modified: 29-AUG-1990    ArticleIdent: Q61592

 The following are the current command-line options (switches) for
 Microsoft Mouse Driver version 7.04:

    Option  Description
    ------  -----------

    /B      Using bus mouse

    /Cn     Using serial mouse on port COMn
            (where:  0 <= n <= 1)

    /Dn     Enabling double-speed threshold
            (where:  0 <= n <= 100)

            0 => No threshold speed (always double speed)
            100 => Maximum threshold speed (rarely double speed)

    /Hn     Setting horizontal sensitivity
            (where:  0 <= n <= 100)

            0 => 0 horizontal mickeys per pixel scaling factor
               (i.e., no horizontal movement returned)
            100 => 100 horizontal mickeys per pixel scaling factor

    /In     Using Microsoft InPort Mouse on primary or secondary InPort
            (where:  n = 1  or  n = 2)

    /L(c)   Selecting language c
            Languages are defined as follows:

               c         Language             Ordinal Value
               -         --------             -------------

           (default)     English                    0
               F         French                     1
               NL        Netherlands (Dutch)        2
               D         German                     3
               S         Swedish                    4
               SF        Finnish                    5
               E         Spanish                    6
               P         Portuguese                 7
               I         Italian                    8
               K         Korean                     9
               J         Japanese                   10

    /Mn     Cursor mask override
            (where:  0 <= n <= 255, n = 0 => mask off)

            0 => Mask off
            Not 0 => Mask on

            (If software cursor is specified in function 10, then set
            cursor to default software cursor. It tells the mouse
            driver to determine which bit pattern to use to make
            the cursor visible.)

    /Nn     Using dampened cursor motion to fix LCD laptop display
            problems
            (where:  0 <= n <= 255)
            (This slows down the screen update rate.)

            0 =>    Skip 0 interrupts (this is, same as normal mouse)
            255 =>  Skip 255 mouse hardware interrupts before
                    processing data

    /Pn     Selecting ballistic curve number n
            (where:  1 <= n <= 4)

            (Note that this may change if the specification changes.)

    /R(n)   Setting interrupt rate
            (where:  1 <= n <= 4, default n = 1)

            1 => 30Hz
            2 => 50Hz
            3 => 100Hz
            4 => 200Hz

    /Sn     Setting both horizontal and vertical sensitivity
            (where:  0 <= n <= 100)

            0 => 0 mickeys per pixel scaling factor
                 (that is, no movement returned)
            100 => 100 mickeys per pixel scaling factor

    /Vn     Setting vertical sensitivity
            (where:  0 <= n <= 100)

            0 => 0 vertical mickeys per pixel scaling factor
                 (that is, no vertical movement returned)
            100 => 100 vertical mickeys per pixel scaling factor

    /Y      Disabling sprite and Video Seven code

            (To disable mouse driver hardware cursor support on
            certain Video Seven and C&T VGA controllers.)

    /Z      Using PS/2 mouse

            (This is added for PS/2 only. It directs the driver to look
            for the mouse at the mouse port.)


 98. Hot Spot Not Displaced Along Horizontal Axis with Driver 7.04

 Product Version(s): 7.04
 Operating System:   MS-DOS
 Flags: ENDUSER |  h_menupr menu programming INT33 MF9
 Last Modified: 27-JUL-1990    ArticleIdent: Q64177

 If mouse driver version 7.04 for the Microsoft Mouse is installed
 without the /Y switch, the hot spot will not be displaced along the
 horizontal axis.

 This problem will occur only in programs that use mouse function 9 to
 set the hot spot. Including a /Y switch when installing the mouse
 driver will eliminate this problem.


 99. Problem with Mouse and PS/2 Model 70A21

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 18-APR-1990    ArticleIdent: Q38654

 Older models of the PS/2 Model 70A21 will not boot with the mouse in
 the mouse port.

 The machine hangs and gives an 8603 error, indicating something is
 wrong with the mouse. The mouse functions properly in the serial
 ports, and an IBM mouse will work in the mouse port with the drivers
 provided by Microosft.

 There is a patch that will correct this problem. Contact Microsoft
 Product Support Services at (206) 454-2030 for this patch.


 100. "Interrupt Jumper Missing" Error Message

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified:  6-DEC-1988    ArticleIdent: Q38754

 The "Interrupt jumper missing" message can appear when installing the
 driver on a bus mouse. This can be caused by several things.

 It frequently appears because the interrupt selected on the
 J4 jumper is conflicting with existing hardware. If the
 IRQ vector is being used by anything else this message will
 appear.

 The message also can appear because the J2 jumper is set on slot 8 and
 not to normal as it should be.

 It also is possible that the interface card is defective. This can
 only be verified by installing the mouse and software onto another
 machine and testing the mouse.


 101. How to Define, Display Graphics Mouse Cursor in FORTRAN 5.00

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | H_fortran
 Last Modified: 10-JUL-1990    ArticleIdent: Q51225

 The following code shows how to define and display a graphics mouse
 cursor in Microsoft FORTRAN version 5.00:

 c This program displays mouse cursor in a shape of a cross.
 c The program terminates when the user presses the ENTER
 c key.

       include 'fgraph.fi'
       include 'fgraph.fd'
       integer*2 m1,m2,m3,m4
       integer*2 mcursor(32)
       integer*2 arrloc(2)
       integer*4 arradds
       equivalence (arrloc(1),arradds)

       do 50 i=1,16                   !define the screen mask
  50      mcursor(i) = #ffff
          mcursor(17) = #0000         !define the cursor mask
          mcursor(18) = #0180
          mcursor(19) = #0180
          mcursor(20) = #0180
          mcursor(21) = #7ffe
          mcursor(22) = #0180
          mcursor(23) = #0180
          mcursor(24) = #0180
          mcursor(25) = #0000
          mcursor(26) = #0000
          mcursor(27) = #0000
          mcursor(28) = #0000
          mcursor(29) = #0000
          mcursor(30) = #0000
          mcursor(31) = #0000
          mcursor(32) = #0000

       m1 = 0
       call mousel(m1,m2,m3,m4)         !reset mouse driver
       dummy = setvideomode($erescolor) !set video mode (EGA)
       m1 = 9
       m2 = 1
       m3 = 1
       arradds = locfar(mcursor) !get address of cursor array
       call mousel(m1,m2,m3,arrloc(1))  !set graphics cursor
       m1 = 1
       call mousel(m1,m2,m3,m4)         !show cursor
       read(*,*)                        !press enter to quit
       m1 = 2
       call  mousel(m1,m2,m3,m4)        !hide cursor
       dummy = setvideomode($defaultmode) !set video mode
       end


 102. Serial Mouse May Hang on ATT 6300

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 10-MAR-1989    ArticleIdent: Q40162

 When either MOUSE.COM or MOUSE.SYS is loaded using a serial mouse on
 some of the ATT 6300's, the machine will hang.

 You can correct this problem by specifying the COM port the mouse is
 attached to by using the /C1 or /C2 command-line switches. You can do
 this either in a manual start up or by including the information in
 the AUTOEXEC.BAT or CONFIG.SYS files.


 103. Mouse and Lotus 1-2-3 Mouse Menu Under Windows/286

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 10-MAR-1989    ArticleIdent: Q41087

 To run Lotus 1-2-3 and the Mouse Menu for Lotus under Windows, the
 123.PIF file included with Windows must be edited. The key point to
 note is that under the "Directly Modifies" option of the PIF file the
 check boxes for both Screen and Memory must be turned on. Add any
 parameters or set the initial directory if necessary. Save these
 changes so you will not have to repeat them again.

 After the 123.PIF file is correctly configured, load the Mouse and
 Menu in memory as you normally would before going into Lotus 1-2-3.
 Bring up Lotus 1-2-3 within Windows and the Menu should function
 correctly. If not, reboot the system from the original floppy DOS disk
 to make sure nothing else in memory is interfering, then load the
 mouse and menu into memory.


 104. ATI Wondercard Graphics Adapter

 Product Version(s): 1.00 2.00
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 13-FEB-1989    ArticleIdent: Q31338

 Certain BIOS versions of the ATI Wondercard Graphics Adapter and
 Microsoft Mouse Driver Versions 6.02, 6.10, 6.11, and 6.14 are
 incompatible. ATI has solved this problem by offering a BIOS upgrade.

 The BIOS version is displayed when booting your computer. If you do
 not know the BIOS version of the Wondercard, reboot the machine. The
 board and BIOS versions that do work together are as follows:

 Board Version                      BIOS Version

    1                             1.16 (or higher)
    2                             2.07 (or higher)
    3                             3.07 (or higher)
    4                             4.07 (or higher)

 It is also possible to disable the VGA emulatoin on the ATI card
 by running SMS (ATI's configuration program) with the following
 paramiters:

             sms egabios   (to disable VGA)
             sms vgabios   (to enable VGA)

 For more information about the BIOS upgrade, contact ATI at the
 following phone number and address:

 (416) 576-0711
 ATI 3761 Victoria Park Ave.
 Unit #2
 Scarborough, Ontario, Canada
 M1W352


 105. BOA Demo Program Does Not Work on AT&T 6300 Computer

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | att
 Last Modified: 20-MAR-1990    ArticleIdent: Q51227

 BOA, the Microsoft Mouse Demo Program, does not work on an AT&T 6300
 computer: it begins to draw a border and then hangs. Otherwise, the
 mouse appears to function correctly.


 106. PC Tools Version 5.00 Needs Mouse Driver Version 6.14 or Later

 Product Version(s): 1.x 2.x 3.x 4.00 4.01
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 17-MAY-1989    ArticleIdent: Q42317

 PC Tools Version 5.00 documentation recommends Version 6.14 or later
 of the mouse driver.


 107. Mouse and Renaissance Legacy II Switch Graphics Adapter

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 20-MAR-1990    ArticleIdent: Q51240

 Problem:

 A serial mouse is installed on a computer with a Renaissance video
 card and the mouse driver reports that it is installed. However, the
 mouse does not respond in programs.

 Response:

 The Renaissance card has an InPort-type mouse adapter, which the mouse
 driver finds before it checks for a serial mouse.

 To correct this problem, include the /C1 or /C2 option on the mouse
 command line to specify where the mouse driver should look for the
 mouse. For example, do the following for COM1:

    mouse /C1


 108. Error in SIMPLE Mouse Menu in Programmer's Reference

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | docerr
 Last Modified: 22-MAR-1990    ArticleIdent: Q51489

 There is an error in the code for SIMPLE Mouse Menu on Page 74 of the
 "Microsoft Mouse Programmer's Reference Guide." The erroneous code
 reads as follows:

    dn:  TYPE 0,801       ;Down-arrow key

 It should read as follows:

    dn:  TYPE 0,80        ;Down-arrow key


 109. cegal() Function in EGA.LIB May Not Work Properly

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 16-APR-1990    ArticleIdent: Q43335

 When using cegal() in the EGA.LIB with Function f1, cegal() doesn't
 perform correctly. An example is shown below.

 Perform the following function in C

    outp(CRTC_INDEX,INDEX);

 where CRTC_INDEX is the port address and INDEX is the register.

 The mouse will not see the change in the EGA register; therefore, the
 above C call may cause the mouse to not perform properly because the
 call bypasses the BIOS routines.

 The following are two ways to perform this call so that the mouse will
 see the change in the EGA register:

 1. Use the EGA.LIB (this does not work):

          e1=0xf1;
          e2=0xd;
          e4=0;
          cegal(&e1,&e2,&e3,&e4,&e5);

 2. Use the equivalent BIOS call (this works):

          inregs.x.ax=0xf1;
          inregs.x.bx=0xd;
          inregs.x.dx=0;
          int86(0x10,&inregs,&outregs);


 110. NOTEPAD.COM Doesn't Work with Extended Keyboard

 Product Version(s): 1.00 1.01 2.00 2.01 2.50 3.00 4.00 5.00 5.02 5.03
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 12-JUN-1989    ArticleIdent: Q43336

 NOTEPAD.COM does not work with keyboards that have the extended
 function keys F11 and F12.

 No resolution to this limitation is expected because NOTEPAD.COM is
 no longer included with the mouse.


 111. Mouse and Token Ring Conflict

 Product Version(s): 7.00
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 22-MAR-1990    ArticleIdent: Q57606

 With the mouse driver installed first, Token Ring does not install
 properly.

 It has been reported that if the mouse driver was loaded after the
 three drivers that are needed for Token Ring, both will work properly.


 112. MS123.COM May Not Work in Lotus 1-2-3 with Look & Link Add-On

 Product Version(s): 1.x
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 12-JUN-1989    ArticleIdent: Q43600

 MS123.COM may not work properly in Lotus 1-2-3 if Look & Link (a Lotus
 1-2-3 add-on by Personics) is being used.

 The workaround is to load MOUSE.SYS in the CONFIG.SYS file instead of
 loading MOUSE.COM in the AUTOEXEC.BAT file.


 113. Microsoft Mouse and the NEC Powermate

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 12-JUN-1989    ArticleIdent: Q43720

 When using the NEC Powermate and the Microsoft Mouse with the Bus
 Interface, you must place the J3 jumper to the secondary setting. The
 Powermate can use the primary addressing for its screen I/O.


 114. MOUSE.COM Solves PS/2 Serial Problems with Ventura Publishing

 Product Version(s): 1.01
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 20-MAR-1990    ArticleIdent: Q43781

 Ventura Publisher uses its own mouse driver for the PS/2 - Serial
 mouse. For the bus mouse, Ventura requires the Microsoft Mouse driver
 (MOUSE.COM) to be loaded.

 If you are experiencing problems using a PS/2 - Serial mouse,
 reinstall Ventura and select the Bus Mouse option.  This will load
 the Microsoft Mouse Driver rather than the driver supplied by Ventura.
 The problems that your experienced with your PS/2-Serial mouse will
 no longer be present.  You DO NOT need to replace your PS/2-Serial
 mouse to choose the bus mouse option.  Selecting the Bus mouse option
 bypasses Ventura's own mouse drivers.



 115. Using the 400 PPI Mouse with GEM

 Product Version(s): 7.00
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 19-MAR-1990    ArticleIdent: Q59313

 When using the 400 PPI Serial Mouse with GEM, the mouse cursor jumps
 all over the screen.

 When installing GEM, select the Microsoft Bus Mouse option, even
 though you are using a serial mouse. When the bus mouse is selected
 during the installation process, GEM will use the Microsoft Mouse
 Driver that is supplied with the mouse.


 116. MS123 Mouse Menu Not Correctly Positioning Cursor

 Product Version(s): 1.x 2.x 3.x 4.x 5.x 6.x 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 29-JUN-1989    ArticleIdent: Q44057

 If you position the Lotus cursor in 1-2-3 with the mouse cursor on an
 "unprotected cell," the Lotus cursor does not stay positioned on the
 cell selected by the mouse. The cursor jumps to the left or right,
 depending on which part of the cell the mouse cursor is located.

 If you position the Lotus cursor with the mouse cursor on "protected"
 cells, the cursor appears to stay positioned.

 One workaround in positioning the Lotus cursor with the mouse is to
 place the mouse cursor on the appropriate arrow keys that appear on
 the right side of the screen, or resort to using the keyboard cursor
 keys.


 117. Finding the COM1: Serial Port on a PC/XT/AT Machine

 Product Version(s): 1.00   | 1.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified: 31-AUG-1989    ArticleIdent: Q44126

 When connecting the Microsoft Mouse serial interface cable to your
 computer, you must first determine the location of the serial port.

 On a PC- or XT-class computer, the serial port is normally the male,
 25-pin, D-shaped connection in the back of the machine.

 On an AT-class computer, the serial connection is normally the male,
 9-pin, D-shaped connection on the back of the computer.

 There are exceptions, but these descriptions are a good rule of thumb.

 Note: If the machine has only one serial port, it should be set up as
 COM1: using IRQ4. If the serial port is set up as COM2: and it is the
 only serial port in the machine, the Microsoft Mouse driver might
 install, but the mouse might not function properly.

 COM3: and COM4: is not supported by the mouse driver.


 118. InPort/Bus Mouse Comparison and Overview

 Product Version(s): 1.00
 Operating System:   OS/2
 Flags: ENDUSER | SR# G890626-21385
 Last Modified: 31-AUG-1989    ArticleIdent: Q46369

 Question:

 Could you clarify the difference between the Microsoft Bus Mouse and
 the InPort Mouse?

 Response:

 The Microsoft InPort device interface is a low-cost graphic device
 interface consisting of a 40-pin custom LSI IC and a compact 9-pin
 circular connector, which supports a variety of graphic input devices,
 especially mice.

 The following is a comparison between old Bus Mouse and new InPort
 Mouse:

 1. The InPort Mouse uses a custom Microsoft designed 40-pin LSI
    interface chip manufactured by OKI Inc. of Japan.

    The Bus Mouse uses a generic Intel 8255A parallel interface chip.

 2. The InPort Mouse allows the CPU interrupt rate to be programmable
    from 0 (no interrupt) to 200 Hz.

     The Bus Mouse CPU interrupt rate is fixed at 30 Hz.

 3. The InPort Mouse interrupts the CPU only when the mouse position
    or button status has changed.

     The Bus Mouse interrupts the CPU constantly regardless of mouse
     (in)activity.

 4. The InPort Mouse requires only two I/O operations to read the mouse
    XY position.

    The Bus Mouse requires four I/O operations to read mouse XY
    position.

 5. The InPort Mouse uses the compact Hosiden 9-pin circular connector.

    The Bus Mouse uses the bulky DB-9 connector.

 When used stand-alone with an IBM XT/AT PC, both mice use an interface
 board that plugs into the standard IBM XT/AT bus. In addition, since
 the InPort custom IC is essentially an enhanced, single-chip version
 of the Microsoft Bus Mouse interface board, other manufacturers can
 easily add the InPort interface to their PC plug-in cards. The
 following are examples:

 1. The Microsoft MACH 10 enhancement board

 2. Renaissance GRX graphics add-in boards

 3. Selected Verticom graphics controllers/adapters come with an InPort
    interface.

 The InPort Mouse can also connect to an RS-232 serial port, or the
 IBM PS/2 mouse port through an external adapter box.


 119. Mouse Driver Conflicts with Novell Network Software

 Product Version(s): 7.00
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 22-MAR-1990    ArticleIdent: Q59314

 Using MOUSE.COM Version 7.00 may cause problems with Novell network
 software.

 Using MOUSE.SYS or loading MOUSE.COM before the network software will
 resolve the conflict.

 Microsoft is researching this problem and will post new information
 here as it becomes available.


 120. Mouse Performance between Serial and Bus Mouse

 Product Version(s): 1.x 2.x 3.x 4.x 5.x 6.x 1.00 1.01
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 31-AUG-1989    ArticleIdent: Q46461

 Summary

 Although there are no differences in functionality between the bus and
 serial mouse, you should be aware that there are differences in the
 way the mouse interrupts the CPU (i.e., the mouse driver must be
 installed).

 The serial mouse is event driven. This means when you neither move the
 mouse nor press a button (i.e., the mouse is not in use), there is no
 degradation to the CPU processing. When the mouse is being used, an
 approximately 5-percent degradation to the CPU performance can occur.

 The bus mouse is not event driven. When you neither move the mouse nor
 press a button, the mouse interrupts the CPU at either the default (30
 Hz) or at the user-defined rate (50, 100, or 200 Hz).


 121. Cadkey and Mouse Driver 7.00

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified:  3-APR-1990    ArticleIdent: Q59859

 If Mouse Driver Version 7.00 is installed when Cadkey is used, the
 mouse is limited to a 1-inch x 1-inch area in the upper left-hand
 corner of the screen.

 Microsoft has confirmed this to be a problem in Mouse Driver Version
 7.00. This problem was corrected in Mouse Driver Version 7.04.


 122. Intermittent Installation on NEC 386 Machines

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified:  3-APR-1990    ArticleIdent: Q59860

 Mouse Driver Version 7.00 causes intermittent installation of the
 mouse on the NEC 386 computers.

 Microsoft has confirmed this to be a problem with the Mouse Driver
 Version 7.00. This problem was corrected in Version 7.04.


 123. 400 DPI Serial Mouse and Northgate Computers

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified:  2-MAY-1990    ArticleIdent: Q59861

 When the 400 PPI PS/2/Serial Mouse is installed on the 9-pin serial
 port of some Northgate Computer, the mouse may not install.

 When the 400 PPI PS/2/Serial Mouse is installed on the 9-pin serial
 port as a serial mouse, it uses pins 2, 3, 4, 5, and 7 to communicate
 with the serial port.

 The other pins in the 9-pin connector are used when the PS/2 adapter
 is connected to the mouse. Pin 8 of the built-in serial port, when set
 to a logic zero, is 1 to 2 volts higher than the voltage that would be
 present on an IBM compatible serial port. When a logic 1 is present on
 pin 8 and the mouse is connected to a 9-pin serial port, the mouse
 cannot reset. This prevents the mouse from installing.

 To work around this problem, do either of the following:

 1. Contact Northgate Technical Services at (800) 445-5037. They have
    found the cause of the problem and will work with you to make the
    necessary corrections to the motherboard.

 2. Use a 9- to 25-pin serial adapter to eliminate the signal from pin
    8. To do this, you need to purchase the adapter from a local
    electronics store. This adapter has a 9-pin female connector on one
    end and a 25-pin male connector on the other end. Once you have the
    adapter perform the following steps:

    a. Attach the adapter you purchased to the built-in serial port of
       your computer.

    b. Attach the mouse to the 25- to 9-pin serial adapter that was
       supplied with your mouse.

    c. Attach this adapter to the 9- to 25-pin adapter that you have
       already attached to your computer.


 124. Mouse Function 9 and Mouse Driver 7.00

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified:  3-APR-1990    ArticleIdent: Q59877

 Mouse Function 9 does not function correctly when Mouse Driver Version
 7.00 is installed. Vertical movement of the hot spot is blocked. The
 symptoms of this are as follows:

 1. The wrong menu item is selected when the mouse buttons are clicked.

 2. The line is drawn above the cursor in a graphics application

 Microsoft has confirmed this to be a problem in Mouse Driver Version
 7.00. This problem was corrected in Version 7.04.

 Major Products: First Publisher
                 Ultravision


 125. MSETUP Deletes Reference to MOUSE.SYS in CONFIG.SYS

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified:  3-APR-1990    ArticleIdent: Q59929

 The MSETUP program that is supplied with the 400 PPI Mouse (Mouse
 Driver Version 7.00 or later) deletes any reference to MOUSE.SYS in
 the CONFIG.SYS file.

 If you are operating under OS/2, do NOT run MSETUP.

 MSETUP deletes the MOUSE.SYS reference in CONFIG.SYS to prevent the
 loading of a older version of the mouse driver when the machine is
 booted.

 Do not run MSETUP on an OS/2 system, and do not load the DOS mouse
 driver to make the mouse work in the DOS box.


 126. Which Mouse Menus Work with Which Version of Lotus

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified:  3-APR-1990    ArticleIdent: Q59932

 Testing of the various versions of Lotus 1-2-3 with each of the
 available MS123 mouse menus and with either the Version 6.24b or
 Version 7.00 mouse driver yield the following results:

    Lotus     |  MS123       MS123-1     MS123-2     MS123-3
    Version   |  6.24b/7.00  6.24b/7.00  6.24b/7.00  6.24b/7.00
    ----------|-----------------------------------------------
      1A      |   yes/yes     yes/yes     yes/yes     yes/yes
              |     */*                                  /**
              |
      2.01    |   yes/yes     yes/yes     yes/yes     yes/yes
              |     */                       /**       **/**
              |
      2.2     |   yes/yes     yes/yes     yes/yes     yes/yes
              |     */*                                 */*
              |
      3.0     |    no/no       no/no       no/no      yes/yes
              |               ***/***     ***/***      **/**

 Notes: *   No mouse action on Master screen.
        **  No side bar menu.
        *** Cursor moves with mouse but no menu action.

 Summary of Normal Mouse Action (Yes in Above Chart)
 ---------------------------------------------------

 Usually, the mouse works in one of two ways: either the selected block
 moves around with the mouse movements, or a separate mouse cursor is
 on the screen and the selected block moves to the mouse cursor
 position upon clicking the left mouse button.

 In most cases, clicking the left mouse button activates a side bar
 menu with options such as page up, page down, page left, page right,
 home, end, and arrow key functions, and sometimes more (depends on the
 version of the menu).

 Also, in most cases, clicking the right mouse menu does the same as
 pressing the "/" (slash) key to bring up the standard Lotus menu.
 Moving the mouse changes the highlighted command. The right mouse
 button acts as an ENTER key. Clicking both buttons will return the
 mouse to the spreadsheet.


 127. Multimate Menu Will Work with Multimate Advantage 4.0

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified:  3-APR-1990    ArticleIdent: Q59934

 Informal testing with the Multimate Advantage II mouse menu has shown
 that it also works with Multimate Advantage Version 4.0.


 128. Pin-Outs of the 9-Pin Hosiden Socket

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified:  8-MAY-1990    ArticleIdent: Q61593

 The following is the signal configuration of the 9-pin Hosiden socket
 on the bus adapter of the Microsoft Mouse:

    Pin          Signal
    ---        ------

    1          +5v
    2           XA
    3           XB
    4           YA
    5           YB
    6           SW1
    7           SW2
    8           SW3
    9           Signal ground
    E           Shield ground


 129. Bus Mouse Port on Leading Edge 386 SX

 Product Version(s): 2.00
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 27-JUL-1990    ArticleIdent: Q64178

 The Leading Edge 386 SX computer has what appears to be a PS/2-style
 mouse port near the keyboard connector. This is actually an inport
 mouse connector designed for a Microsoft-compatible bus mouse,
 according to Page 6-13 of the "Leading Edge 386 SX User's Guide." The
 connection is a standard hosedin connector for an inport mouse.

 There is one switch that may or may not be in the correct position to
 install the mouse. This is Switch 3 on the motherboard. This must be
 in the ON position or the mouse will not install.


 130. Practical Peripherals and Serial Mouse Configuration

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | mouse modem practical peripherals
 Last Modified: 15-NOV-1990    ArticleIdent: Q66536

 If the Microsoft serial mouse is connected to COM 1, then a Practical
 Peripherals 2400 baud rate modem cannot be configured as COM 2.  This
 modem/mouse combination may work for a while, but eventually it
 will fail to an I/O address conflict between the mouse and the modem.

 Practical Peripherals technical support ([818] 991-8200)
 confirms this to be a problem.  They recommend that the modem be
 configured as COM 3 or COM 4.  The mouse should then remain on COM 1
 to separate the I/O addresses as much as possible.


 131. Serial Mouse with Timeline

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 13-JAN-1991    ArticleIdent: Q67339

 To use the Microsoft Serial Mouse with Timeline, a Symantec
 Corporation project management application, load the mouse driver by
 invoking MOUSE.SYS in the CONFIG.SYS file. Symantec Corporation
 technical support confirms that the Microsoft Mouse will not work
 correctly with Timeline if you use the MOUSE.COM driver file.


 132. 386MAX.SYS with MOUSE.COM 7.0 Can Hang Sprite Video Cards

 Product Version(s): 7.00 7.03 7.04
 Operating System:   MS-DOS
 Flags: ENDUSER | SR# S901024-6 B_BasicCom
 Last Modified: 15-NOV-1990    ArticleIdent: Q66561

 When used with 386MAX.SYS version 4.05 (an expanded memory driver by
 Qualitas Software), Microsoft Mouse driver versions 7.00, 7.03, and
 7.04 can hang computers equipped with video cards that have sprite
 capabilities (the ability to have a graphic cursor in text mode).

 This problem only occurs with the above mentioned versions. Earlier
 versions of the Microsoft Mouse driver will not cause this problem.

 Using Mouse driver version 7.04 with the "/y" line option will fix
 this problem.
 e.g.
     in DOS:

       mouse /y

  or in the AUTOEXEC.BAT:

       C:\MOUSE1\MOUSE /Y



 133. Correct Mouse Drivers for Express Publisher

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | driver mouse express publisher
 Last Modified: 13-JAN-1991    ArticleIdent: Q67340

 The application Express Publisher requires the 7.04 mouse
 driver to run correctly. Other mouse driver versions will not work
 according to the manufacturers, Power Up Software Corporation
 of San Mateo, CA.



 134. Trail of Multiple Cursors in Desqview 386

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | cursors trail mouse port setup
 Last Modified: 13-JAN-1991    ArticleIdent: Q67341

 If the Microsoft Serial Mouse is connected to a mouse port in a PS/2
 style machine, you may see a trail of red cursors inside the windows
 of Desqview 386 when you use QEMM 5.0.

 This is not a problem with the mouse. This problem occurs if you have
 selected "serial" in the port selection for the mouse when you set up
 Desqview. If you select "add-on board" for the mouse port selection in
 the Desqview Setup program, the mouse cursor will display normally.
 Note: This problem will not occur if the mouse is connected to the
 serial port.


 135. Mouse Menu Key Sequences: Corrections and Additions

 Product Version(s): 1.x 2.x 3.x 4.x 5.x 6.x 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | key sequence mouse menu docerr
 Last Modified: 10-FEB-1991    ArticleIdent: Q67854

 Page 71 of the "Microsoft Mouse Programmer's Reference Guide" lists
 "Key Sequences That Can't Be Simulated" using the menu programming
 TYPE statement. These keys cannot be simulated in a mouse menu because
 the key or key sequence is suppressed in the ROM BIOS. The list that
 is presented in the guide is incomplete, and in certain instances it
 is in need of revision.

 Each suppressed key mentioned is the lowercase character on the key.
 It is understood, but not explicitly stated, that the uppercase
 character on these keys will also be suppressed. A number of keys and
 key combinations that are suppressed and cannot be emulated are not
 mentioned in the guide. Some of the additions and corrections that can
 be made to the published list are given below.

 KEY COMBINATIONS FOR 83-KEY KEYBOARD
 ------------------------------------

 For the IBM PC and compatibles with a standard 83-key keyboard,
 the following keys and key combinations are suppressed.

 NOTE: Where applicable the uppercase character is given in
 parentheses.

 In Combination With the ALT Key
 -------------------------------

 RIGHT TAB
 ` (~)
 \ (|)
 ALT
 HOME
 PG UP
 NUMPAD 5
 NUMPAD
 +
 END
 PG DN
 INS
 DEL

 In Combination with the CTRL Key
 --------------------------------

 CTRL
 ` (~)
 NUMPAD 5
 NUMPAD
 +

 KEY COMBINATIONS FOR 84-KEY KEYBOARD
 ------------------------------------

 For the IBM AT and compatibles with a 84-key keyboard, the following
 keys and key combinations are suppressed:

 In Combination with the ALT Key
 -------------------------------

 ` (~)
 \ (|)
 TAB (right and left)
 ALT

 With ALT and on the Numeric Keypad
 ----------------------------------

 7 (HOME)
 1 (END)
 5
 0 (INS)
 9 (PG UP)
 3 (PG DN)
 - (SYS RQ)
 +

 In combination with the CTRL Key
 --------------------------------

 ENTER
 CTRL

 With CTRL and on the Numeric Keypad
 -----------------------------------

 5
 - (SYS RQ)
 +

 For the IBM PS/2 and compatibles with a 101- and 102-key keyboard, the
 following keys and key combinations are suppressed:

 In combination with the ALT key and on the Numeric Keypad
 ---------------------------------------------------------

 7 (HOME)
 1 (END)
 5
 0 (INS)
 9 (PG UP)
 3 (PG DN)
 - (SYS RQ)
 +

 In combination with the CTRL Key
 --------------------------------

 ` (~)
 CTRL
 ALT
 SCROLL LOCK

 With CTRL and on the Numeric Keypad
 -----------------------------------
 +

 EXCEPTIONS AND CORRECTIONS
 --------------------------

 The exceptions and corrections to the list of suppressed key and key
 combinations given on pages 71-72 of the "Microsoft Mouse Programmer's
 Reference" (Copyright 1989) are noted below.

 The followings key combinations can be represented using
 extended-keyboard-scan codes with the IBM PS/2 and compatibles with a
 101- and 102-key keyboard:

    ALT+BACKSPACE
    ALT+ESC
    CTRL+INS
    CTRL+TAB

 The ALT key used in combination with any one of the following keys can
 also be represented using extended-keyboard-scan codes for the IBM
 PS/2 and compatibles with a 101- and 102-key keyboard:

    [    ]
    ;
    '
    -
    ,
    .
    /
    *

 The CTRL key used in combination with the RIGHT ARROW and LEFT ARROW
 key can be represented on the PC, AT, and PS/2 keyboards.

 For more information about this topic, see "The Programmer's PC
 Sourcebook," pages 400-406; the "IBM PC/AT Technical Reference," pages
 4-21 and 5-14 to 5-23; and the "IBM PS/2 Hardware Technical
 Reference," pages 41-49.


 136. The Microsoft Mouse with Lotus 1-2-3 Release 3.1

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 10-FEB-1991    ArticleIdent: Q67860

 You can use the Microsoft Mouse with Lotus 1-2-3 version 3.1. The
 mouse will work correctly with both the COM and SYS versions of the
 drivers. Correct mouse use in 1.2.3 release 3.1 depends on whether or
 not the memory resident formatting and printing utility WYSIWYG is
 properly installed and loaded into memory. Without installation and
 loading of WYSIWYG, no mouse cursor will appear on the normal Lotus
 1-2-3 screen. If you try use a previous Lotus 1-2-3 Microsoft Mouse
 menu or the generic MSMENU, Lotus will not work correctly (for
 example, you will get erratic highlights and no cursor).

 It appears that in some instances there is a problem with earlier
 versions of the mouse driver even when WYSIWYG is correctly installed
 and loaded. A possible solution is to update the mouse driver to
 MOUSE.COM version 7.04. Another possible solution is to load MOUSE.SYS
 version 7.04 with the CONFIG.SYS file.

 Correct use of the mouse in Lotus 1-2-3 version 3.1 depends on proper
 installation of WYSIWYG, correct hardware configuration, and the right
 operating environment.

 Installation
 ------------

 The following steps are necessary to ensure that the Microsoft Mouse
 will work with Lotus 1-2-3 version 3.1:

  1. Complete installation of the mouse hardware and software. Be sure
     the mouse driver is loaded into memory.

  2. Complete the first-time installation of Lotus 1-2-3 3.1. If you did
     not choose to have the WYSIWYG files transferred to the hard disk
     the first time, you must rerun the installation program from the
     hard disk and choose the option to transfer the WYSIWYG files to
     the hard disk.

  3. After completing the first installation of Lotus 3.1, put the
     Add-In Support Disk into drive A and type "install" (without the
     quotation marks) at the A:> prompt. The installation program will
     place the WYSIWYG files into the default directory C:\123R3\ADDINS.

  4. When this second "install" is complete, go to the C:\123R3
     subdirectory and type "123". This takes you into the normal Lotus
     screen.

  5. Press the ALT+F10 key combination. You will see the Addin menu in
     the Lotus menu bar area.

  6. From the Addin menu, choose Load.

  7. Specify WYSIWYG.PLC as the add-in to read into memory.

  8. Select No-Key.

  9. WYSIWYG is now in memory, and you have a mouse cursor.

 10. You can get the regular Lotus menus by selecting Quit or using the
     key combination CTRL+BREAK. You also may toggle between the Addin
     menu and the main Lotus menu by clicking the right mouse button.

 Hardware
 --------

 You must have a mouse and mouse driver as well as a graphics
 display monitor and a graphics display card. Lotus 1-2-3 3.1
 also requires at least a 286 microprocessor.

 Operating Environment
 ---------------------

 Lotus 1-2-3 3.1 requires MS-DOS version 3.00 or later. It will not run
 in the DOS compatibility box of OS/2; however, it will run after you
 choose the DOS dual-boot option from OS/2. Lotus 1-2-3 3.1 will run
 under the DOS option of Windows 3.00 or it can be installed as a
 Windows 3.00 application.

 Additional Tips
 ---------------

 Microsoft Mouse Driver versions 7.03 and 7.05 will return a white
 arrow graphics cursor in Lotus 1-2-3 3.11 while all other mouse driver
 versions will return a blue graphics cursor.

 To select an item from a menu you must point to the menu item desired
 and hold the left mouse button down. Then move the highlight to the
 sub-menu choice. When you release the mouse button, the item will be
 selected.

 In addition to normal mouse cursor movement, you may also move the
 mouse cursor by selecting the arrow icons on the right hand side of
 the 1-2-3 screen.


 137. Running MSETUP from Drive B

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | driver mouse install b: msetup
 Last Modified: 10-FEB-1991    ArticleIdent: Q67862

 When you run the Setup program from drive B, the message "please
 insert disk into drive A" may occur. You can temporarily force drive B
 to emulate drive A. Using the DOS ASSIGN command, type

    ASSIGN A=B

 at the C:\DOS> prompt. Then, run MSETUP from drive B. After rebooting
 the system, the drives will return to their normal configuration.



 138. 400 DPI Serial Mouse and Epson Equity LT 386/SX

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 12-FEB-1991    ArticleIdent: Q67863

 The 400 DPI serial mouse may not install on the 9-pin serial port of
 an Epson Equity LT 386/SX. Epson America has confirmed this and offers
 a patch for this problem. You can obtain this patch from your Epson
 dealer.

 Note: Not all Epson dealers may be aware of this problem, but they
 should be able to get the patch from their main Epson supplier.



 139. Quattro Pro 2.0 Graphics Mode Needs /Y Switch

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 10-FEB-1991    ArticleIdent: Q68106

 Borland's Quattro Pro 2.0 requires mouse switch /Y when you run the
 7.04 mouse driver in graphics mode. This information is contained in
 the readme file that accompanies Quattro Pro 2.0.

 The graphics mode in Quattro Pro 2.0 is known as the "Annotate" mode.
 Owners of the Microsoft Mouse and Quattro Pro 2.0 also report that the
 earlier version 6.24b mouse driver will work in any mode of Quattro
 Pro 2.0. Borland recommends that you should not use a Microsoft Mouse
 driver earlier than version 6.10.


 140. I/O Addresses for the Microsoft Mouse

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 10-FEB-1991    ArticleIdent: Q68110

 The following are the ranges in which an I/O (Input/Output) port
 assignment may occur for the Microsoft Mouse. The ranges are given in
 hexadecimal numbers, and the serial communications port assignments
 conform to the IBM standard I/O address range assignments for PCs and
 PS/2s.

 SERIAL MOUSE
 ------------

 Port Assignments    Address Ranges
 ----------------    --------------

 COM1                3F8H-3FFH

 COM2                2F8H-2FFH

 BUS MOUSE (BUS INTERFACE BOARD SETTINGS)
 ----------------------------------------

 Primary Inport Range
 --------------------

 23CH-23FH

 Secondary Inport Range
 ----------------------

 238H-23BH

 An I/O port acts as a doorway through which information travels.
 Information may originate from the CPU, travel over data and address
 buses, pass through the I/O port, and finally reach a peripheral
 device such as the mouse. Although the CPU recognizes various ports
 through 16-bit port numbers that range from 00H through FFFFH, the
 port address is not actually an address found in main memory. A port
 assignment is a memory location separate from a (main) memory address
 that is associated with that particular I/O port.

 No other peripheral device, such as a modem or printer, may share the
 same I/O address with the mouse or the mouse may not function
 correctly.


 141. Pascal Example in Programmer's Guide Won't Compile

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | Pascal Mouse Programming Borland Turbo
 Last Modified: 11-FEB-1991    ArticleIdent: Q68881

 The "Making Calls from Borland Turbo Pascal Programs" sample in
 Appendix E of the "Microsoft Mouse Programmer's Reference" does not
 compile with Turbo Pascal versions 5.0 and 6.0.

 The CpuReg data structure needs to be defined as "Registers"
 variables. The semicolons need to be removed from the END lines that
 immediately precede ELSE. Finally, finding the segment and offset of
 the pointer of the address of the user array or subroutine (functions
 9,12,20,22,23,and 24) needs to be done outside of this procedure.
 Passing the first element of the array or the start point of the
 subroutine into the procedure, then calling the "ofs" and "seg"
 functions in the procedure doesn't seem to work. This is due to how
 the variables get dereferenced when passed into a procedure.

 The following example compiles in both Turbo Pascal version
 6.0 and Quick Pascal version 1.00:

 Procedure Mouse (Var m1, m2, m3, m4, m5 : integer );

 Var
    CpuReg: Registers;

 begin {mouse}

    if m1 >= 0 then
       begin
      CpuReg.AX := m1;        { Load Parameters       }
      CpuReg.BX := m2;        { into appropriate      }
      CpuReg.CX := m3;        { registers             }

      if (m1 = 9) or (m1 = 12) or (m1 = 20)
         or (m1 = 22) or (m1 = 23) or (m1 = 24) then
         begin
           CpuReg.DX  :=  m4;    {m4 = offset,         }
           CpuReg.ES  :=  m5;    { and m5 = segment    }
         end                       { of the user array }
                          { or subroutine     }

       else
       if  m1 = 16  then
        begin
          CpuReg.CX  := m2;           {Left  x coordinate }
          CpuReg.DX  := m3;           {Upper y coordinate }
          CpuReg.SI  := m4;           {Right x coordinate }
          CpuReg.DI  := m5;           {Lower y coordinate }
        end
      else
          CpuReg.DX  := m4;

      Intr($33, CpuReg);              {Call mouse driver  }
                             { at Interrupt 33H  }

      m1 := CpuReg.AX;                {Return values back }
      m2 := CpuReg.BX;                { to parameters     }
      m3 := CpuReg.CX;
      m4 := CpuReg.DX;

      if (m1 = 20) then               {special returns    }
         m2 := CpuReg.ES              { from subroutines  }
    end;
 end; {mouse}


 142. CADKEY Requires Microsoft Mouse Driver Version 7.04

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | AutoCAD EasyCAD FastCAD VersaCAD
 Last Modified: 10-FEB-1991    ArticleIdent: Q68930

 The CAD software package CADKEY requires that the Microsoft Mouse
 driver be updated to version 7.04 to run properly. Earlier
 versions of the driver, such as version 7.00, will not allow you to
 operate the mouse correctly in this software. In one instance, the
 cursor is confined to a small area of the upper-left-hand corner of
 the screen.

 CADKEY is produced and marketed by CADKEY Inc. The technical support
 number is (203) 647-9235. The CADKEY Inc. product referenced here is
 manufactured by vendors independent of Microsoft; we make no warranty,
 implied or otherwise, regarding the product's performance or
 reliability.


 143. Using the Microsoft Mouse with Open Access III

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 10-FEB-1991    ArticleIdent: Q68931

 The Microsoft Mouse can be successfully used with the application Open
 Access III by performing the following steps:

 1. Copy the Open Access III files MMENU.DEF and MMENU.MNU to the
    MOUSE1 subdirectory.

 2. Copy the file MENU.COM to the MOUSE1 subdirectory.

 3. Load the Microsoft Mouse driver.

 4. Go to the MOUSE1 subdirectory and type:

       MENU MMENU

    You should get a "Menu Installed" message.

 5. Go to the Open Access III subdirectory and start the Open Access
    III program.

 If this sequence does not work, you may have problems with memory
 resident software. In which case, perform the above steps after doing a
 "clean boot" with a copy of the original DOS floppy disk.

 You may obtain the MENU.COM program by calling Microsoft Product
 Support (Hardware).

 Open Access III is an integrated function application that combines a
 database, a word processor, and a spreadsheet into one application.
 The product is developed and marketed by Software Products
 International. The technical support number is (800) 937-4774.

 The Software Products International product referenced here is
 manufactured by a vendor independent of Microsoft; we make no
 warranty, implied or otherwise, regarding the product's performance or
 reliability.


 144. False Cursor Trail in SimEarth with Mouse Driver 7.00

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 10-FEB-1991    ArticleIdent: Q68932

 Microsoft Mouse Driver version 7.00 displays a false cursor trail in
 the planet simulation program SimEarth. You may temporarily correct
 this problem by using a /B switch when loading SimEarth (that is
 SimEarth /B).

 For a permanent fix you can obtain an updated mouse driver from Microsoft
 Product Support or Microsoft Customer Service.

 More info:

 SimEarth is developed and marketed by Maxis. The technical support
 number is (415) 376-6434. The Maxis product referenced here is
 manufactured by a vendor independent of Microsoft; we make no
 warranty, implied or otherwise, regarding the product's performance or
 reliability.


 145. Microsoft Mouse Incompatible with Commodore PC 40-III

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 10-FEB-1991    ArticleIdent: Q68953

 The Commodore PC 40-III and PC 10-III may not work with the Microsoft
 Serial Mouse. The mouse port for these machines is not designed to
 function with the Microsoft Mouse.

 You may obtain further information and assistance by calling Commodore
 technical support at (703) 644-4170. The Commodore product referenced
 here is manufactured by a vendor independent of Microsoft; we make no
 warranty, implied or otherwise, regarding this product's performance
 or reliability.


 146. Using a Bus Mouse on a Tandy 1000

 Product Version(s): 1.x 6.x 7.x
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 12-FEB-1991    ArticleIdent: Q68955

 When using a bus mouse on a Tandy 1000 computer, you may not be able
 to run the mouse on IRQ2. A better choice may be IRQ5, even though the
 computer may have a hard drive.

 The early models of the Tandy 1000 used IRQ2 for a hard card, which
 may have been optionally installed. These models included the Tandy
 1000, Tandy 1000A, Tandy 1000SX, and Tandy 1000TX.

 Later models used IRQ5 for hard cards. These models included the
 Tandy 1000SL, Tandy 1000SL/2, Tandy 1000TL, and Tandy 1000TL/2.


 147. WordPerfect 5.1 and WordStar 6.0 Mouse Support

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | word processor
 Last Modified: 10-FEB-1991    ArticleIdent: Q68956

 WordPerfect version 5.1 incorporates Microsoft Mouse support; however,
 WordStar versions 5.5 and 6.0 do not. The following information
 identifies whether or not a menu is needed to use the Microsoft Mouse
 with WordStar or WordPerfect.

 Product                  Description
 -------                  -----------

 WordStar version 6.0     Not Microsoft Mouse aware: see below note
 WordStar version 5.5     Not Microsoft Mouse aware: uses MSWS5.COM
 WordPerfect version 5.1  Microsoft Mouse aware: no menu needed
 WordPerfect version 5.0  Not Microsoft Mouse aware: uses MSWP5.COM

 Note:
 WordStar 6.0 sometimes works with MSWS5.  But we do not gurantee this
 version to work with WS 6.0.

 It is important to learn how the built-in mouse menus in WordPerfect
 version 5.1 work. In color modes, the normal cursor is a rectangular
 red text cursor. A right-button click causes a menu line to appear at
 the top of the screen. Then, by clicking and holding the left mouse
 button, you may drag the highlight down the chosen drop-down menu to
 make the desired menu selection.

 The products referenced here are manufactured by vendors independent
 of Microsoft; we make no warranty, implied or otherwise, regarding
 these products' performance or reliability.


 148. Using MSMENU.COM with ACT! version 2.0

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 11-FEB-1991    ArticleIdent: Q68958

 You can use the Microsoft Mouse with ACT! version 2.0. In order to use
 the mouse correctly, you must first load the generic menu DEFAULT.COM
 or MSMENU.COM. Appendix H-1 of the ACT! "Reference Manual" specifies
 DEFAULT.COM, but the more current MSMENU.COM or MENU.COM work as well.

 Copy one of these files to the ACT! subdirectory. The directions for
 ACT! specify that you:

 1. Load the mouse.

 2. In the subdirectory in which ACT! is installed, type "MSMENU MSACT"
    (without the quotation marks).

 3. After the menu is loaded in this way, type "ACT!" (without the
    quotation marks). You will now have the use of the mouse in ACT!

 The file MSACT.MSE is a menu file that comes with ACT!. If the mouse
 and menu are loaded properly, then the mouse should give basic cursor
 movement with the buttons serving the following functions:

    Button                   Function
    ------                   --------

    Left Button Click        Same as ENTER
    Right Button Click       Same as F2 (edit mode)
    Both Buttons Click       Same as ESC

 Note: These button assignments may not work properly in DOS 4.00.

 If you do not have a copy of MSMENU.COM, you may obtain a copy by
 calling Microsoft Customer Service or Product Support and ordering
  "The Microsoft Mouse Supplemental Menus Disk."

 ACT! is a database software program that helps keep track of business
 contacts. ACT! is developed and marketed by Contact Software
 International. The technical support number is (214) 418-4885. The
 Contact Software International product referenced here is
 manufactured by a vendor independent of Microsoft; we make no
 warranty, implied or otherwise, regarding this product's performance
 or reliability.


 149. NEC Mouse Port, Lotus 3.1, and Microsoft Serial Mouse

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | NCR
 Last Modified: 10-FEB-1991    ArticleIdent: Q68959

 The mouse cursor may freeze when you use the Microsoft Mouse in the
 PS/2 mouse port of some of the NEC 286 and 386 machines while running
 the WYSIWYG mode of Lotus 1-2-3 version 3.1. Contact NEC technical
 support at (508) 264-4300 for more information.

 The products included here are manufactured by vendors independent of
 Microsoft; we make no warranty, implied or otherwise, regarding the
 products' performance or reliability.

