Microsoft Programmer's Library 1.3/Microsoft_Programmers_Library.7z/MPL/pas/pasknl.txt

Text File | 2013-11-08 | 1.4 MB | 42,178 lines

 Microsoft PASCAL Compiler
 =============================================================================


 1. Restoring Remapped Interrupt Vectors

 Product Version(s): 3.3x
 Operating System:   MS-DOS
 Flags: ENDUSER | TAR53039
 Last Modified: 23-FEB-1988    ArticleIdent: Q11709

 Problem:
    When you define interrupt service routines using Microsoft Pascal
 Version 3.3x under MS-DOS, the interrupt vector will not always be
 restored to its original value after program termination.

 Response:
    Pascal will not allow you to automatically restore remapped interrupt
 vectors. If you want to remap interrupt vectors, you will have to use
 DOS functions 25H and 35H to both change and explicitly restore the
 vectors.


 2. Pascal 3.32: Reading Unlocked Records after Locked Records

 Product Version(s): 3.32
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist3.32 ptr62966
 Last Modified: 17-MAR-1988    ArticleIdent: Q27205

 Problem:
    If I lock a range of records in a data file over a network, a
 second user attempting to read these records will get read error 11
 (protected file or record) as expected. However, if the second user
 consecutively reads locked records and then unlocked records, he will
 still get read errors attempting to read the unlocked records.
    For example, if records number two and three are locked and records
 four and five are unlocked, a second user reading records two and
 three will get read errors as expected. If the second user then
 attempts to read unlocked record numbers four and then five, he will
 still get read errors.

 Response:
    This is a verified problem with Pascal Version 3.32. It will be
 corrected in a future release of Pascal.
    To work around the problem, you must read the unlocked records in
 non-consecutive order after reading locked records.
    If you read the last locked record whose record number is N, the
 next attempted read of any unlocked record other than number N+1 will
 succeed. After reading locked record number N, attempting to read
 unlocked record number N+1 will fail, and consecutively reading
 unlocked record numbers N+2, N+3, N+4 and so on will also fail.
    One method to avoid this problem would be to re-attempt reading a
 record after trapping a read error. If the record is unlocked, the
 second read attempt will succeed.
    Depending on which records are locked in the file, other methods to
 avoid this problem may include resetting the file before reading
 unlocked records, or skipping one or more records before the next
 read.


 3. STACK Entry in MS-DOS and XENIX

 Product Version(s): 3.30 3.31
 Operating System:   XENIX
 Flags: ENDUSER | TAR55715 docerr
 Last Modified: 26-SEP-1988    ArticleIdent: Q11816

 Question:

 Page 79 of the XENIX "Microsoft Pascal Compiler User's Guide" displays
 a memory map. For the STACK entry, it says that this is provided for
 compatibility with MS-DOS. But under XENIX, the STACK is reserved by
 it and not in DGROUP. However, when you use the -F option to set the
 stack, the effect is as if the stack is in DGROUP. For example,
 setting the stack bigger makes the heap smaller (I get out of heap
 errors), and making the stack smaller makes the errors go away. Does
 the -F option not only affect the XENIX Stack but also the DOS
 compatibility stack?

 Response:

 The information on page 79 is incorrect. Both DOS and XENIX place
 the stack in DGROUP. The documentation insinuates that there are two
 stacks; however, there only is one. Thus, the heap is reduced when the
 stack size is increased.


 4. Flushing I/O buffers

 Product Version(s):
 Operating System:   MS-DOS
 Flags: ENDUSER | TAR56140
 Last Modified: 25-FEB-1988    ArticleIdent: Q11872

 Product: PASCAL 3.31

 Question:
    I have a large application written in MS-Pascal and I would like to force
 the flushing of the I/O buffer. The file is open in DIRECT mode and is a
 binary file.  Is there any way to do this short of closing and reopening the
 file?

 Response:
    At this time, there is no way to flush the I/O buffer without closing the
 file.



 5. Use of the /STACK Linker Switch

 Product Version(s): 3.20 3.3x
 Operating System:   MS-DOS
 Flags: ENDUSER | TAR56601
 Last Modified: 23-FEB-1988    ArticleIdent: Q11963

 Question:
    I am using Version 3.2 of Microsoft Pascal and having problems with
 stack overflow. I use the /STACK linker switch to increase the size of
 the stack and everything seems to be fine but the documentation in
 both the 3.2 and 3.3 manuals says not to use the /STACK switch. Am I
 likely to have a problem with this? If so, what can I do?

 Response:
    In the 3.2 version, it is possible for a program to cause the stack
 size to increase or decrease. Setting a stack size with the linker
 switch and then having that size changed by a program could cause
 unpredictable results. This is the reason that you should not use the
 /STACK switch.
    In Version 3.3x, the stack size is fixed by the compiler so
 changing the stack size when linking is acceptable. You will find more
 information on the /STACK linker switch in the README.DOC file that
 accompanies the 3.31 version of the product.


 6. Symbol Defined More than Once Linking with FORTRAN Library

 Product Version(s): 3.3x
 Operating System:   MS-DOS
 Flags: ENDUSER | TAR56929
 Last Modified:  3-OCT-1988    ArticleIdent: Q11984

 Question:

 In the process of adding a Pascal language-user interface to our
 FORTRAN language system, a run-time library compatibility problem has
 surfaced. Any time we search both run-time libraries during a link, a
 "Symbol defined more than once: `SUBSQQ'" error is reported in the
 second run-time library searched.

 This is both an operational problem (our MAKEs terminate at the error)
 and a potential run-time problem. The only run-time problem we know
 about is when the FORTRAN substring is used (i.e.,  TEST(I:I)=' ') and
 the Pascal library is searched first. This will generally lock up a
 system at run-time.

 We would like to know the following:

 1. Is there a fix for the libraries?

 2. Is there a potential Pascal run-time problem when we link the
    FORTRAN library first to solve the FORTRAN substring crash?

 Response:

 No. You are not likely to have a problem in using the executable that
 you created.

 For the first problem, with the MAKE file, you should use conditional
 execution based on whether or not you receive certain error levels.

 With regards to the library problem, the information that you sent
 would suggest that you have a FORTRAN main program that calls Pascal
 routines that, for example, provide a user interface to your system.
 But there is something in the structure of your program that tangles
 the linker, which is NOT your fault.

 If you look at the contents of the FORTRAN and Pascal libraries using
 the "LIB" utility, you can see that the function SUBSQQ is present in
 both PASCAL.LIB and FORTRAN.LIB. You can see that the object module
 that contains the SUBSQQ function in the Pascal library contains many
 other entry points, in contrast to the FORTRAN object module
 containing SUBSQQ, which only has three entry points.

 PASCAL.LIB:

 sets              Offset: 000101d0H  Code and data size: 4c5H
   ADDSQQ            CEQSQQ            CLESQQ            CLTSQQ
   MIN               MULSQQ            O3ESQQ            SETSQQ
  *SUBSQQ*           T3OSQQ            Z3RSQQ

 FORTRAN.LIB:

 fstl              Offset: 0000fb00H  Code and data size: 19eH
   FCPSQQ            FSTLQQ            SUBSQQ

 An entry point is not necessarily a function. For example, in the
 FORTRAN library module containing SUBSQQ, FCPSQQ is actually a module
 name, while SUBSQQ is a procedure and FSTLQQ a function.

 Your program uses at least one entry point contained in both of these
 two modules. The entry point does not necessarily have to be SUBSQQ.

 For example, if you link the Pascal library First, then the FORTRAN
 library, and if your program generates calls to ADDSQQ and FSTLQQ, the
 linker will first pull in the "sets" module from the PASCAL.LIB to
 resolve the reference to ADDSQQ. Then it would have to pull in the
 "fstl" module from the FORTRAN.LIB to resolve the reference to FSTLQQ.
 Then it will check all of its entry points for duplicates. The linker
 would find that now it has duplicates of the SUBSQQ procedure, and
 generate a message that you have pulled in two (possibly different)
 versions of SUBSQQ.

 This process should not generate a fatal error, and you should be able
 to proceed. If it is fatal and hangs your machine, try switching your
 link order.

 Because you are using two Microsoft compilers, and because you are
 using the same version number of two particularly compatible compilers
 (they share the same source code for many routines), the process
 should work properly.

 The SUBSQQ procedure is identical in the FORTRAN and
 Pascal Version 3.31.

 You should proceed with the executable that you created by linking in
 FORTRAN first and then PASCAL. You should not have any problems.


 7. ANDRQQ Should Return REAL8

 Product Version(s): 3.31 3.32
 Operating System:   MS-DOS
 Flags: ENDUSER | TAR54013 buglist3.31 fixlist3.32
 Last Modified:  3-OCT-1988    ArticleIdent: Q12391

 Function andrqq() returns a REAL4 value instead of a REAL8 value when
 the parameter is an arithmetic expression and it has been linked with
 DECMATH.LIB.

 y and z should be the same, but y is only accurate to seven digits.

 Microsoft has confirmed this to be a problem in Version 3.31. This
 problem was corrected in Version 3.32.

 The following code demonstrates the problem:

     {$decmath+}
    var w,x:real8;
         y,z:real8;
    function andrqq(consts a:real8):real8;extern;
        w:=12345678.1234;
        x:=1234567812.34;
        y:=andrqq((w*100));
        z:=andrqq(x);


 8. Compiling in Parent Directories

 Product Version(s): 3.3x
 Operating System:   MS-DOS
 Flags: ENDUSER | TAR51090 buglist3.30 buglist3.31 fixlist3.32
 Last Modified: 22-FEB-1988    ArticleIdent: Q12393

 Problem:
    PAS1 and FORTRAN's FOR1 do not accept the .. (parent directory)
 path designator. For example, if THIS.PAS and THAT.FOR are in my
 parent directory and PAS1.EXE and FOR1.EXE are in the parent's
 subdirectory, PAS1 ..\THIS and FOR1 ..\THAT generate error messages.
 Note: LINK version 3.x and the C compiler driver CL do accept
 the .. path designator.

 Response:
    This problem was corrected in Version 3.32.


 9. Bad code generated for ADS assignment in Version 3.31

 Product Version(s):
 Operating System:   MS-DOS
 Flags: ENDUSER | TAR57668
 Last Modified: 25-FEB-1988    ArticleIdent: Q12396

 Subject:   Bad code generated for ADS assignment

 Product: PASCAL 3.31

 Problem:
    Bad code is generated when assigning a element of ADS record to the offset
 of an ADS variable.  This problem occurs in versions 3.30 and 3.31.

 Response:
    This problem is corrected in the version 3.32 release.

 EXAMPLE PROGRAM:

 program temp(input, output);

   type
     boxg_rec = record
       next : word;
       case btype : word of
         1   : (l_lit    : word);
         2   : (d_handle : word);
       {end case}
     end{record};

     boxg_ary = array [1..10] of boxg_rec;

   var
     boxgary_ads : ads of boxg_ary;
     i           : integer;

 begin
   boxgary_ads^[i].next := (ads boxgary_ads^[i+1]).r;
 end.

 3.30 and 3.31 produces the following code - for the assignment;

   REPZ
   STOSB

 3.20 produces this code.

   MOV       AX,0006H
   MUL       I
   LES       BX,BOXGAR
   ADD       BX,AX
   ADD       AX,FFFAH
   MOV       DX,BX
   LES       BX,BOXGAR
   ADD       BX,AX
   MOV       ES:[BX],DX


 10. BRTEQQ and Windows Development

 Product Version(s): 3.3x
 Operating System:   MS-DOS
 Flags: ENDUSER | TAR51995 buglist3.30 buglist3.31 fixlist3.32
 Last Modified: 23-FEB-1988    ArticleIdent: Q12397

 Problem:
    In Pascal.lib, the routine BRTEQQ accepts one parameter but ends
 with a RETF instead of a RETF 2. When running under Windows, this
 causes the routine EQCLQQ to jump back into the middle of itself when
 it does a RET to the epilogue code. We have tried to patch BRTEQQ but
 LINK4 will not produce an EXE file if there is a "variable already
 declared" error. Looking at BRTEQQ in general, it will not behave
 correctly with the Windows stack structure.

 Response:
    This problem was corrected in Version 3.32.


 11. Pascal Has No Append Mode for Sequential Files

 Product Version(s): 3.1x 3.20 3.3x
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified:  4-APR-1988    ArticleIdent: Q28288

    Pascal has no append mode for text and other sequential files. To
 add data to an existing sequential file, you must create a new
 sequential file with the Rewrite procedure. Then, use the Reset
 procedure to open your existing file, read the data, and write it to
 the newly created file. Once your old file's data has been written to
 the new file, you may write additional data to the new file.
    The DOS Copy command may be used to append files together, as in
 the following command:

 copy file1 + file2

    Please note that you can append to direct access files by use of
 the Reset procedure. This procedure is documented on Page 266 of the
 Version 3.32 "Microsoft Pascal Compiler Reference" manual.


 12. Error Accessing the I/O Addresses

 Product Version(s): 3.3x 4.00
 Operating System:   MS-DOS
 Flags: ENDUSER | docerr
 Last Modified: 26-SEP-1988    ArticleIdent: Q29805

 The port attribute does not allow Pascal programs to access I/O
 addresses as documented at the top of Section 11.5.3 on Page 142 of
 the "Microsoft Pascal Compiler Reference Manual."

 The port attribute is designed to behave like the origin attribute, as
 stated in Appendix B.2 "Implementation Restrictions" of the "Microsoft
 Pascal Compiler User's Guide."

 Both the origin and port attributes direct the compiler to locate a
 variable at a specified memory address.


 13. File Sharing Mode Fails in Version 3.31

 Product Version(s): 3.31 3.32
 Operating System:   MS-DOS
 Flags: ENDUSER | TAR53822 buglist3.31 fixlist3.32
 Last Modified:  3-OCT-1988    ArticleIdent: Q12400

 Reading and writing a file with file-sharing mode set will not work
 correctly under Version 3.31 of Pascal.

 If the mode of the file is set to sm_DENYNONE, it will read up to the
 583rd byte of the record, then go back and read from the beginning
 instead of reading the rest of the file. The problem does not appear
 if the file sharing is not set. It does not matter if SHARE.EXE is
 loaded or not.

 This problem occurs when the share modes are sm_DENYWR, sm_DENYRD, and
 sm_DENYNONE. It appears to work correctly under sm_COMPAT and
 sm_DENYRW.

 The sample program below writes 26 30-character strings in a 780-byte
 direct-access record. Each of the 26 strings is filled with a
 different letter of the alphabet.

 The following code demonstrates this problem:

 program testit(input,output);
 type test_rec=record
               line:array[1..26] of string(30);
               end;

 var
   i,j,k:integer;
   go_again:char;
   test:test_rec;
   test_file:file of test_rec;

 begin
   assign(test_file,'testfile');
   test_file.mode:=direct;
   for i:=1 to 4 do begin
     for j:=1 to 26 do
       for k:=1 to 30 do
         test.line[j][k]:=chr(j +96);
     test_file.share:=sm_DENYRW;
     rewrite(test_file);
     seek(test_file,i);
     test_file^:=test;
     put(test_file);
     close(test_file);

     test_file.share:=sm_DENYNONE;
     reset(test_file);
     seek(test_file,i);
     get(test_file);
     test:=test_file^;
     close(test_file);

     writeln(output);
     writeln(output,'Record : ',i:2);
     writeln(output);
     for j:=1 to 13 do begin
       write(output,'  ',j:2,' : ',test.line[j]);
       writeln(output,'   ',(j+13):2, ' : ',test.line[j+13]);
     end;
     writeln(output);
     write(output,'enter a key to go to next record --> ');
     readln(iniput,go_again);
   end;  {for i:=1 to 4}
 end.


 14. READs and WRITEs to Binary File Cause Crash in Version 3.31

 Product Version(s): 3.31 3.32
 Operating System:   MS-DOS
 Flags: ENDUSER | TAR52819 buglist3.31 fixlist3.32
 Last Modified:  3-OCT-1988    ArticleIdent: Q12402

 The program below uses READs and WRITEs to a binary sequential file.
 It crashes the system in Version 3.31, but works properly in Version
 3.30. If GETs and PUTs are used instead, the program executes
 successfully. According to the standard, it is legal to use READs and
 WRITEs on a binary sequential file.

 Microsoft has confirmed this to be a problem in Version 3.31. This
 problem was corrected in Version 3.32.

 The following code demonstrates this problem:

 {$LINE+}
 program test(input,output);
 TYPE BUFF=ARRAY[0..511] OF INTEGER;

 VAR  BFILE:FILE OF BUFF;
      FNAME:LSTRING(80);
      DATA:BUFF;

      I:INTEGER;
 BEGIN
      FNAME:='CU.DAT';
      ASSIGN(BFILE,FNAME);
      REWRITE(BFILE);
      FOR I:=0 TO 511 DO
       DATA[I]:=I;
      WRITE(BFILE,DATA);
      CLOSE(BFILE);

      RESET(BFILE);
      FOR I:=0 TO 511 DO
       DATA[I]:=0;
      READ(BFILE,DATA);
      FOR I:=0 TO 511 DO
       WRITELN(DATA[I]);
      CLOSE(BFILE);
 END.


 15. Compiler and Heap Management Error Messages

 Product Version(s): 3.3x
 Operating System:   MS-DOS
 Flags: ENDUSER | TAR52075 buglist3.31 fixlist3.32
 Last Modified:  3-OCT-1988    ArticleIdent: Q19725

 Question:

 The compiler behaves very inconsistently. When trying to compile a
 file, for example xx.PAS, "pas1 xx;" sometimes works correctly, but
 "pas1 xx,,list;" gives "Error: compiler pointer to disposed var."

 Changing the name of the listing file, "pas1 xx,,lis;" sometimes works
 properly. This problem occurs when compiling exactly the same source
 file; different results are produced by changing the invocation line.
 The different error messages are as follows:

       "Error: Compiler Invalid Pointer Range"
       "Null Pointer Assignment"
       "Compiler Pointer To Disposed Var"

 Response:

 Microsoft has confirmed this to be a problem in Version 3.31. This
 problem was corrected in Version 3.32.


 16. Windows Development for 80386 Requires Pascal Version 3.32+

 Product Version(s): 3.3x
 Operating System:   MS-DOS
 Flags: ENDUSER | TAR58979
 Last Modified: 29-FEB-1988    ArticleIdent: Q19931

 Problem:
    My Windows application written in Pascal runs correctly on my 80286
 machine, but crashes on my 80386 machine.

 Response:
    You must compile Windows applications with the Pascal Version 3.32
 (or higher) compiler and libraries in order to run the application on an
 80386 machine.


 17. Floating-Point Libraries for Windows

 Product Version(s): 3.3x 4.00
 Operating System:   MS-DOS
 Flags: ENDUSER | TAR59216
 Last Modified:  3-OCT-1988    ArticleIdent: Q19940

 Problem:

 I am having trouble getting my Windows application to link without
 errors. It is a Pascal program and I am using floating-point
 calculations. I am specifying the following libraries to the linker
 and I am receiving unresolved externals such as "_fpmath" and
 "_fptaskdata":

 paslibw pascal math llibc /nod

 Response:

 You need to include the following as your linker library:

 altmath paslibw pascal mlibc libh/NOD

 The altmath should be linked first to override the Pascal library that
 would disable the floating point. Also, with Pascal Versions 3.x, only
 the alternate math package is supported in Windows.


 18. Duplicate Code Generated for a Function Call

 Product Version(s): 3.32 4.00 | 4.00
 Operating System:   MS-DOS    | OS/2
 Flags: ENDUSER | TAR61145 buglist3.32 buglist4.00
 Last Modified: 18-AUG-1988    ArticleIdent: Q22514

 Problem:
    Under certain circumstances, the startup code and call to a
 user-defined function is followed by an exact duplicate of the startup
 code and function call, i.e., the function is called twice.
    This process rarely occurs, but it has been reported to happen when
 a function call is made as one of the arguments to another function or
 procedure call.

 Response:
    Microsoft has confirmed this to be a problem in Versions 3.32 and
 4.00. We are researching this problem and will post new information as
 it becomes available.
    You can work around the problem by using a temporary variable to
 receive the result of the function call, and then use the temporary
 variable within expressions.


 19. Comparing Floating-Point Numbers

 Product Version(s): 3.13 3.20 3.3x 4.00
 Operating System:   MS-DOS OS/2
 Flags: ENDUSER | TAR61353
 Last Modified: 29-SEP-1988    ArticleIdent: Q22589

 Question:

 It seems that comparing a VAR and a CONST produces a condition
 resulting in FALSE while the two values are equal. The following
 program is an example:

    PROGRAM RE(INPUT,OUTPUT)
    CONST
    H=199.33;
    VAR R:REAL4.
    BEGIN
    R:=H;
    WRITELN(R);
    IF R=H THEN WRITELN('OK');
    END.

 Executing this program never gives the equality between R and H. Is
 this problem due to a difference between the internal format
 representation?

 Response:

 First, real constants use eight bytes. Because the decimal fraction .33
 cannot be exactly represented in binary, the eight-byte constant will
 have more significant digits than the four-byte variable, making the
 comparison between them false.

 Second, be aware of the way real numbers are internally represented in
 a computer. Because these numbers are stored in a binary
 floating-point format, it is impossible to represent all decimal real
 numbers exactly, and a conversion from binary to decimal may result in
 some degree of inaccuracy.

 Because the conversion process is not always exact, conditional tests,
 rounding or truncating routines, and conversions are not always
 reliable. Therefore, we recommend that if they are used, they be used
 with caution.

 Do not compare floating-point numbers for equality due to the
 conversion problems. Instead, compare a floating-point number to a
 range of values. For example, to compare a single-precision
 floating-point variable "x" to 1.0, the following expression could be
 used:

 if ((x <= 1.001) AND (x >= 0.999)) then
    writeln('x = 1.0');

 If you would like a more detailed description of the floating-point
 format, we recommend that you refer to the following articles:

 1. A three-part series on real-number representations in "PC Tech
    Journal" running in the October, November, and December 1984 issues

 2. An article titled "Arithmetic On Your PC" by Peter Rice in the
    March 1985 issue of "BYTE" magazine


 20. No Unique Serial Number on Registration Card

 Product Version(s): 3.13 3.20 3.3x
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 18-FEB-1988    ArticleIdent: Q22738

 Question:
    I am trying to fill out the registration card, but am
 unable to access the 16-digit serial number that you ask
 for. I am following the instructions, but no serial number
 appears in the right-hand corner. What am I doing wrong?

 Response:
    There is no unique serial number for this product. The
 instructions you are referring to pertain to Microsoft Word
 users only. You should skip this part of the registration
 card, fill out the rest, and send it in.


 21. Sending Output to the Printer

 Product Version(s): 3.13 3.20 3.3x
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified:  3-OCT-1988    ArticleIdent: Q22829

 Question:

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

 Response:

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

 1. Prn
 2. Lpt1
 3. Lpt2

 The following example sends output to the printer:

    PROGRAM EXAMPLE(INPUT,OUTPUT);
     VAR F:TEXT;
     BEGIN
      ASSIGN(F,'PRN');
      REWRITE(F);
      WRITELN(F,'OUTPUT NOW GOES TO THE PRINTER');
      CLOSE(F);
     END.

 The ASSIGN statement associates the TEXT file variable F with the
 system file PRN. The REWRITE statement opens the printer for output,
 and the WRITELN statement sends output to the file F, which is the
 printer.

 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 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.


 22. Pascal Constants and Concatenation Operator

 Product Version(s): 3.3x
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified:  3-OCT-1988    ArticleIdent: Q23439

 Question:

 Is there a way to indicate in the source file the continuation of a
 line when declaring a constant that is longer than 80 characters? If
 so, what would the continuation character be?

 Response:

 There is no continuation character; however, you may use the string
 concatenation operator (*) with string constants to declare a constant
 longer than 80 characters. The following is an example:

    const a = 'hello'
          b = ' there'
          c = a * b
          { c = 'hello there'}

 This information is documented in Section 10.6 (Pages 125-127) in the
 "Microsoft Pascal Compiler for the MS-DOS Operating System Reference
 Manual" for Version 3.32.


 23. Stack and Heap Growth

 Product Version(s): 3.3x
 Operating System:   MS-DOS
 Flags: ENDUSER | docerr
 Last Modified: 26-SEP-1988    ArticleIdent: Q23693

 Problem:

 Section 10.3.2 (Page 116) in the "Microsoft Pascal Compiler User's
 Guide" states that the stack grows down and the heap grows up and that
 they "grow toward each other." However, according to the memory model
 in the README file, the stack would have to grow up and the heap down
 for them to grow toward each other.

 Response:

 In MS-DOS Pascal Versions 3.3x, the stack and heap do grow apart. They
 grow toward each other in Version 3.20. The error in the documentation
 is a result of incomplete changes in the documentation from Versions
 3.2 to 3.3x.


 24. Units and Interfaces Versus Modules

 Product Version(s): 3.20 3.3x
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 18-FEB-1988    ArticleIdent: Q23666

 Question:
    What is the advantage of using units and interfaces over
 modules?

 Response:
    The purpose of units in Microsoft Pascal is to allow
 programmers to port programs written in UCSD Pascal to
 Microsoft Pascal more easily. We recommend the use of
 modules over units. Modules are more straightforward,
 clearer, and easier to use.


 25. Error 2033 in Pascal Compiler 3.32

 Product Version(s): 3.32
 Operating System:   MS-DOS
 Flags: ENDUSER | TAR62947 buglist3.32 fixlist4.00
 Last Modified: 18-AUG-1988    ArticleIdent: Q23616

    Version 3.32 of the Pascal compiler generates the "2033 Invalid
 Pointer Range" error for the code segment below.
    Note that Pascal Version 3.31 runs correctly without any errors.
    Microsoft has confirmed this to be a problem in Version 3.32. This
 problem was corrected in Pascal Version 4.00.

    The following is the sample code segment:

    {$debug-}
    program test(input,output);

      var
        config_name : lstring(20);

      procedure get_config;
        var
          config_file  : file of integer;
        begin
          assign(config_file,config_name);
          close(config_file);
        end;{get_config}

     procedure copy_screen;
        type
          video_screen = ads of array[0..16383] of byte;
        var
          plane0,plane1 : video_screen;
        begin{copy_screen}
          plane0.s:=16#b800;
          plane0.r:=0;
          plane1.s:=16#b800;
          plane1.r:=16#4000;
          plane1^ := plane0^
        end;{copy_screen}
    {-------------------------------------------------------}

      begin
        config_name := 'config.mcb';
        copy_screen;
    {$debug+}
        get_config;
      end.



 26. Linking DOS2PAS.LIB and MS-DOS Version 2.00

 Product Version(s): 3.3x
 Operating System:   MS-DOS
 Flags: ENDUSER | docerr
 Last Modified: 26-SEP-1988    ArticleIdent: Q23697

 Problem:

 Page 35 in the "Microsoft Pascal Compiler User's Guide" discusses how
 linking with the DOS2PAS.LIB file will cause your program to use the
 MS-DOS Version 2.00 file system. I cannot find this .LIB file on any
 of my disks.

 Response:

 This file is included only in MS-DOS Pascal Compiler Version 3.20. It
 is not included with Versions 3.3x. The user's guide is incorrect.


 27. Determining Available Memory

 Product Version(s): 3.3x
 Operating System:   MS-DOS
 Flags: ENDUSER | docerr
 Last Modified:  4-NOV-1988    ArticleIdent: Q23698

 Question:

 The example on Page 164 in the "Microsoft Pascal Compiler User's
 Guide" does not work correctly. How can my Pascal program determine
 how much memory is available?

 Response:

 The example on Page 164 only applies to Version 3.20 of the Microsoft
 Pascal Compiler. The documentation is in error; in Version 3.20,
 CESXQQ:2 contains the upper memory limit. However, in Version 3.3x,
 CESXQQ:2 contains the top of DGROUP.

 There is no way to determine how much memory is available directly
 from a Pascal Version 3.3x program. However, you may link in an
 assembly routine that makes a call to DOS with the Setblock function
 call (Function 4A).

 An example of a program that returns available memory is available as
 an application note called "V 3.3x Available Memory." This application
 note is available by contacting Microsoft Product Support Services at
 [phone].


 28. Overlaying Data with the Overlay Linker

 Product Version(s): 3.13 3.20 3.3x
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 18-FEB-1988    ArticleIdent: Q23755

 Question:
    How do I overlay data using the overlay linker?

 Response:
    Microsoft Linker only allows the overlaying of code, so
 it cannot be used to overlay data. There are third-party
 linkers that work with Microsoft products to allow the
 overlaying of data.


 29. No Implementation of SHL, SHR, and ISR Operators

 Product Version(s): 3.11 3.13 3.20 3.3x 4.00 | 4.00
 Operating System:   MS-DOS                   | OS/2
 Flags: ENDUSER | docerr
 Last Modified: 18-AUG-1988    ArticleIdent: Q23758

 Question:
    Page 6 in the "Microsoft Pascal Compiler Reference" manual states
 that SHL, SHR, and ISR are not implemented features; however, Page 151
 in Section 12.1 implies that these operators are available. Which part
 of the manual is correct?

 Response:
    Section 12.1 of the "Microsoft Pascal Compiler Reference" manual is
 incorrect. Microsoft Pascal Compilers Versions 3.11 to 4.00 (Version
 4.00 being the most recent version) do not implement the SHL, SHR, and
 ISR operators. This information is also in the "Microsoft Pascal
 Compiler User's Guide" in Appendix B.3 under "Unimplemented Features."


 30. PAS3 Generates File Access Errors

 Product Version(s): 3.1x 3.20 3.3x
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 18-FEB-1988    ArticleIdent: Q23877

 Question:
    Why does pass three generate the error message "File
 access error in file PASIBF.OID", and an error code such as
 1032"?

 Response:
    The purpose of PAS3 is to generate a code file in which
 the Pascal source code has been translated into assembly
 code. When PAS3 is run, it looks for two files it assumes
 were created by PAS2. These two files are PASIBF.OID and
 PASIBF.TMP. PAS2 will create these files only if you
 requested a code file when you ran PAS1.
    PAS1 requests the names of four files: the source,
 object, listing, and code files. In order to run PAS3, you
 must explicitly give the code file a name. If you use the
 default (type ENTER), it assumes you do not want a code
 file; thus, running PAS3 will generate the file access
 error.
    More information on this topic can be found in Section
 3.2 of the "Microsoft Pascal Compiler User's Guide."


 31. Clearing Screen and Locating Cursor

 Product Version(s): 3.1x 3.20 3.3x
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified:  3-OCT-1988    ArticleIdent: Q23884

 Question:

 How do I clear the screen and locate the cursor?

 Response:

 Microsoft Pascal does not directly support operations such as clearing
 the screen and locating the cursor. This is because these operations
 are machine dependent and Microsoft compilers are designed to support
 a variety of MS-DOS machines.

 There are several ways to perform these machine-dependent operations.
 One is to call assembly-language routines that you or someone else has
 written. There are several excellent third-party graphics packages
 available for Microsoft compilers.

 Another method is to use ANSI or VT52 escape sequences. To use these,
 you must have either the ANSI or the VT52 screen driver installed. For
 example, if a computer has ANSI.SYS on its system disk, and the
 CONFIG.SYS file contains the file DEVICE=ANSI.SYS, that computer has
 the ANSI driver installed.

 The ANSI escape sequence for clearing the screen is "{esc}[2J".
 Therefore, to clear the screen in Pascal with the ANSI driver
 installed, execute the following procedure:

    Procedure ClearScreen;         {uses ESC 2 J to clear the screen and}
    Var  line:lstring(4);          {move the cursor to the home position}
    Begin
      line[1] := chr(27);          {escape character}
      line[2] := '[';
      line[3] := '2';
      line[4] := 'J';
      line[0] := chr(4);           {number of characters}
      Write(line)
    End;                           {ClearScreen}


 32. Fixup Overflow Error While Linking

 Product Version(s): 3.3x
 Operating System:   MS-DOS
 Flags: ENDUSER | docerr
 Last Modified: 18-AUG-1988    ArticleIdent: Q23888

 Problem:
    I am linking my Pascal Version 3.32 program with an assembler
 module; I am following the instructions on Page 98 in the "Microsoft
 Pascal Compiler User's Guide." However, the linker is generating the
 error message "Fixup overflow..."

 Response:
    There are several probable sources for this problem, as follows:

    1. The documentation on Page 98 of the Pascal user's guide is
       incorrect. The guide shows the correct interface to assembly for
       Version 3.20, not for Version 3.3x. Version 3.3x uses a different
       memory model than does Version 3.20; as a result, you need a
       slightly different interface. The correct way to use an assembler
       module with Pascal is given in Appendix A of the user's guide, in
       Section A.12. If you are using the correct interface to your
       assembly code, your problem may lie elsewhere.
    2. Other causes of this error are described in the Pascal user's
       guide in the error messages section. Specifically, this part of
       the manual contains a section of linker error messages, in which
       there is a Fixup Overflow entry.
    3. If a segment is larger than 64K bytes (Point 1 under the Fixup
       Overflow entry), the typical reason is that the global data from
       all object files has been accumulated into the default data
       segment (Dgroup). The solution in this case is to declare ADS OF
       arrays. You then can keep arrays out of the default data segment
       by allocating them on the long heap with the function ALLMQQ or
       GETMQQ, using the ADS variables to keep track of the addresses
       where the arrays are located. See the user's guide under "Long
       Heap Allocation."
    4. If a code segment exceeds 64K bytes, you will have to break up
       the respective source file. A map file with a code segment larger
       than FFFF hexidecimal indicates this condition. If a map file
       cannot be created, link a single-object file by itself. Assuming
       there is less than 64K bytes of data declared in the object's
       source-code file, a Fixup Overflow for a single-object file
       indicates that the code exceeds 64K bytes. (Generally, you also
       will see numerous unresolved reference errors, which you may
       ignore for the purpose of this test.)


 33. Inconsistency in Truncating Numeric Constants

 Product Version(s): 3.31 3.32
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist3.32
 Last Modified:  5-MAY-1988    ArticleIdent: Q24062

 Problem:
    The compiler seems to be inconsistent in truncating numeric
 constants longer than 31 characters. Appendix B.2 in the "Pascal
 User's Guide" states that numeric constants can have up to 31
 characters and, like identifiers, numeric constants longer than 31
 characters are truncated.
    However, declaring a constant with this property does not cause
 Pas1 to generate warning message 104 "number too long - truncated." In
 fact, the constant is not truncated.
    This is inconsistent with Appendix B.2.

 Response:
    This problem is under review and will be considered for inclusion
 in a future release.


 34. Stack-Overflow Error

 Product Version(s): 3.3x
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified:  3-OCT-1988    ArticleIdent: Q24251

 Question:

 What is causing the error message "Stack Overflow" in my program? Can
 I work around it?

 Response:

 The usual source of this error is the allocation of too much space to
 variables in the 64K default data segment, especially large arrays. To
 avoid this problem, declare the arrays as ADS arrays and move them out
 of the default data segment. To move them out, allocate the arrays on
 the long heap with the function ALLMQQ or GETMQQ (these functions are
 described in the "Microsoft Pascal Compiler for the MS-DOS Operating
 System User's Guide").

 Another source of this error is having too many local variables in
 procedures and functions. These variables are allocated on the stack,
 which by default has a size of 2K. If there are too many of them, they
 will overflow the stack.

 To correct this problem, increase the stack size just prior to run
 time by using the EXEMOD utility (this utility comes with the
 compiler). At the DOS prompt, enter a line similar to the following:

 EXEMOD FOO.EXE /STACK <size of the stack>

 The size of the stack must be entered as a hex number between 0 and
 FFFF, inclusive. (Due to some overhead, the maximum stack size for a
 program is actually around FFE0 hex.) This number represents the
 number of bytes that will be reserved for the stack. For efficiency,
 increase the size of the stack by increments of 1K or 2K at a time,
 until a suitable stack size is found. It is not necessary to create
 more stack space than is needed.


 35. "256 VAR or CONST Parameter Types Not Identical" Error

 Product Version(s): 4.00   | 4.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | buglist3.32 fixlist4.00
 Last Modified: 26-SEP-1988    ArticleIdent: Q32409

 In Pascal Version 3.32, you can pass an lstring variable by
 reference (using VAR or VARS) to a function or procedure whose
 corresponding formal parameter is declared as a longer lstring type.
 This process allows the lstring to be overwritten in the function or
 procedure without detection, resulting in corruption of data declared
 after the lstring.

 In Pascal Version 4.00, this problem is detected by the compiler,
 resulting in the "256 VAR or CONST Parameter Types Not Identical"
 error. The following program demonstrates a way to work around this
 type checking. Note that passing lstrings of a long type to a
 procedure whose formal lstring parameter is of a shorter type
 generates the error.

 The program below is used to pass varying length lstrings by
 reference to a procedure.

 The lstring super type should be used for the procedure's formal
 parameter declaration to avoid the "256  VAR or CONST Parameters Not
 Identical" error when passing VAR(S) lstring arguments whose types are
 of variable lengths.

 Variables of the lstring super type cannot be assigned to directly, so
 a maximum-length local lstring (255) is loaded with characters, and
 the length of the local lstring is assigned the length of the lstring
 variable. The local lstring then is copied into the lstring variable
 by the copystr procedure.

 With Pascal Version 3.30, there is a problem with passing lstrings
 by reference (VAR or VARS). If a variable of a short lstring type was
 passed by VAR(S) to a procedure or function whose corresponding formal
 parameter was a longer lstring type, the actual short lstring could be
 overwritten without detection, corrupting data declared after the
 shorter lstring.

 This problem was corrected in Pascal Version 4.00; however, numerous
 programs depend on this Pascal Version 3.30 problem. The following
 program provides the same function, but avoids the possible data
 corruption:

 program test_variable_len_lstr_arg(input,output);
     var  global_ls : lstring(10);

     procedure Proc(var ls_parm : LSTRING);
         var local_ls : lstring(255);
     begin
       {make assignment to local lstring,
       and set it's length to the parameter lstring
       }
         local_ls := 'xxxxxxxxxxxxxxxxx';
         local_ls.len := ls_parm.len;
       {copy local lstring into global lstring}
         copystr(local_ls,ls_parm);
         writeln;
         write('In procedure.');
         writeln(' After copying local lstring to global lstring parameter,');
         write('local lstring = ', local_ls, ', ');
         writeln('lstring parameter = ', ls_parm)
     end;

 begin
     global_ls := 'original';
     writeln;
     writeln('In main, global lstring = ', global_ls);
     writeln('Call procedure, passing lstring by reference (var).');
     Proc(global_ls);
     writeln;
     writeln('Retured to main, global lstring = ', global_ls)
 end.


 36. Seek Subroutine Will Not Seek to Same Record Twice

 Product Version(s): 3.31 3.32
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist3.32
 Last Modified:  5-MAY-1988    ArticleIdent: Q24422

 Problem:
    The Seek subroutine does not work correctly if one attempts to seek
 to the same record more than once. The only way to seek to a record
 that already has been "visited" is to perform a Reset on the file.

 Response:
    Microsoft is researching this problem and will post new information
 as it becomes available.
    Use the following method to work around the problem:

    1. Open the file.
    2. Seek to the desired record.
    3. Reset the file.
    4. Seek to the record again.


 37. Trapping Run-Time File System Errors

 Product Version(s): 3.1x 3.20 3.3x
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified:  3-OCT-1988    ArticleIdent: Q25361

 Question:

 Is it possible to trap run-time file-system errors?

 Response:

 You can trap run-time file-system errors by using the
 TRAP flag, as in the following sample program:

 program file_error_trapping(input,output);
   var
     myfile: text;
   begin
     myfile.trap:=true;           {turns on error trapping}
     assign(myfile,'foo.dat');
     reset(myfile);               {if the file does not
                                   exist then myfile.errs
     if myfile.errs = 10 then      will be set to 10 }
     begin
       writeln('myfile.errs = ', myfile.errs);
       writeln('file not found');
       writeln('it will be created ');
       myfile.errs = 0;           {set myfile.errs back to 0}
       rewrite(myfile);
       writeln(myfile, 'this is a test');
       close(myfile);
       writeln(' file foo.dat has been created');
     end;
 end.

 MYFILE.TRAP initially is set to false. If an I/O error occurs, the
 program will abort. If MYFILE.TRAP is set to true, then error trapping
 for file MYFILE will be turned on. If an I/O error occurs, the value
 in MYFILE.ERRS will be set to the appropriate error-code number, and
 the attempted file operation will be ignored. At this point, you
 should examine the error and write an error-trapping routine.

 Note: once MYFILE.ERRS is set, it does not automatically get set back
 to 0 once the error routine has been executed. Therefore, MYFILE.ERRS
 should be set to 0 to assure that I/O operations are not ignored.


 38. Change to MSINSTALL for XENIX Pascal

 Product Version(s):
 Operating System:   XENIX
 Flags: enduser |
 Last Modified: 24-FEB-1988    ArticleIdent: Q10280

 PRODUCT:  PASCAL/3.30

 DESCRIPTION:
 Filenames in Pascal, Fortran, and C are the same in the same directory.
 The libraries have the same names as the C libraries but different content.
 This means to us that you cannot have Pascal, C, and Fortran installed at
 the same time !

 MICROSOFT RESPONSE:

 We named these files with the same names because they are exactly the same
 files.  The FORTRAN and Pascal runtimes needed portions of the C runtimes,
 so we included them as is.  There should be no problem copying these all on
 1 directory as long as the user copies the latest ones over the older ones.

 Because of possible confusion, we have rewritten the install program
 (msinstall) to do checking for the file creation dates.  What the compiler
 does now is warn the user that if there are old versions of the libraries,
 it WILL NOT write over these libraries.  It writes these libraries (if they
 are present) out to temporary files.  Then it checks to see if there are
 temporary files (i.e. there were libraries present before msinstall was
 invoked) and if they are present, it copies these original libraries back
 to the filenames that the compiler looks for.

 If the user later wants to use the new libraries, the install program can
 be run again, after the original libraries are renamed to different
 filenames. Please note that these C libraries ARE necessary for Pascal and
 FORTRAN now. You can indeed have C, Pascal, and FORTRAN on one system.
 Indeed, you can have different versions of each of these products on the
 same machine also.

 If you want to have different versions of the same product on the same
 machine, you may do one of the following:

 (1) Alter the msinstall program.  The msinstall program first checks to see
 if there are current C libraries.  If there are C libraries already
 existing on the system, msinstall will rename all of these copies of the
 libraries.  It then checks to see if there are these old library files. If
 there are old library files, it copies these files back into the original
 names, which are the filenames that the compiler searches for.  What you
 can do is delete the section of the msinstall program that copies the old
 library files back to the original filenames.  This would mean that then
 the msinstall program will backup your library files, and then install the
 new versions of these files.  This would be very simple to do.

 (2) Alter the cl driver.  Create a driver that would look for the filenames
 of the old library files instead of the new files.  Then you could use
 multiple versions on your machine, invoking the newest version with the cl
 driver and the older version with your altered driver.  This would be more
 complicated and would require a programmer with more skill, but it is
 possible.

 If any users have additional questions about the installation procedure, we
 would suggest that they first read the msinstall program to see what it
 does, and then contact Microsoft OEM customer support with specific
 questions.


 39. XENIX Pascal/FORTRAN cl Driver

 Product Version(s):
 Operating System:   XENIX
 Flags: enduser |
 Last Modified: 24-FEB-1988    ArticleIdent: Q10283

 PRODUCT:  PASCAL/3.30 Beta

 Question:
 The Pascal driver has the same filename as the Fortran driver (CL) which
 means to us that two compilers cannot be installed on the same system at
 the same time.

 Response:
 The CL driver is exactly the same for Microsoft Fortran as it is for
 Pascal.  This driver can link Fortran and Pascal programs. The driver
 checks the extension of the file. An extension of "f" for FORTRAN or
 "p" for Pascal will determine which compiler is used.


 40. Documentation on Command Line Switches is Incorrect

 Product Version(s): 3.20
 Operating System:   MS-DOS
 Flags: ENDUSER | docerr
 Last Modified: 18-AUG-1988    ArticleIdent: Q10285

 Question:
    Concerning Table 18.6, "Command Line Switches" on Page 347 of the
 "Microsoft Pascal Reference" manual for Version 3.20, and Table 5.2,
 "Pass One Compiler Switches," on Page 51 of the "Microsoft Pascal
 Compiler User's Guide;" which one of the two lists is correct?
    Concerning the switch /L; does this refer to the SYMDEB debugger
 that comes with Microsoft Macro Assembler, or the DOS Debug?

 Response:
    Table 18.6, on Page 347 of the Pascal reference manual is
 correct.
    The debugger is SYMDEB. Debug does not detect line numbers.


 41. Example of Using VECTIN Procedure

 Product Version(s):
 Operating System:   MS-DOS
 Flags: enduser |
 Last Modified: 24-FEB-1988    ArticleIdent: Q10286

 PRODUCT:  PASCAL/3.20

 Question:
 Please give me an example of how to use the VECTIN procedure.

 Response:

 program EXAMPLE(input,output);

 {******************************************************************
 NOTE: THIS PROGRAM USES THE VECTIN PROCEDURE ALONG WITH THE DISBIN
 AND ENABIN PROCEDURES.  IT IS INTENDED TO ILLUSTRATE IMPLEMENTING A
 SUBSTITUTE DEFAULT DIVIDE BY ZERO ERROR HANDLER.  WHEN THE PROGRAM
 RECEIVES A DIVIDE BY ZERO, IT EXECUTES THE PROCEDURE "WORLD" INSTEAD
 OF THE NORMAL INTERRUPT 0 PROCEDURE.
 *******************************************************************}

 {******************************************************************
 ********** (1) DECLARE VARIABLES AND EXTERNAL PROCEDURES **********
 *******************************************************************}

 var
      HELLO : word;
      VAR1, VAR2, ZERO : integer;

 procedure disbin; extern;
 procedure enabin; extern;
 PROCEDURE VECTIN(HELLO:word;procedure world[interrupt,public]);extern;
 PROCEDURE PTYUQQ (W:word;x:adsmem);extern;

 {******************************************************************
 ***** (2) THIS IS THE PROCEDURE EXECUTED INSTEAD OF THE    ********
 *****     NORMAL INTERRUPT 0 PROCEDURE                     ********
 *******************************************************************}

 procedure world[interrupt,public];
         begin
                 {NOTE: WHEN THIS "WORLD" PROCEDURE IS EXECUTED,
                  INSTEAD OF EXECUTING THE NORMAL PROCEDURE, THE
                  FOLLOWING MESSAGE WILL BE PRINTED}

                 writeln ('Yea, verily, the vectin procedure worked.');
                 write ('Instead of executing the normal divide by zero');
                 writeln(' interrupt, a procedure ');
                 writeln('printing this message was executed instead.');
         End;

 Begin

 {******************************************************************
 ***** (3) THESE EXPLANATORY NOTES WILL BE PRINTED WHEN YOU     ****
 *****     EXECUTE THIS PROGRAM.  THEN IT WILL PROMPT YOU FOR   ****
 *****     THE INTERRUPT VECTOR NUMBER THAT YOU WANT TO REPLACE ****
 *******************************************************************}

 writeln(' ');
 WRITELN('NOTE:  Please enter the interrupt vector number "0" below.');
 writeln(' ');
 WRITELN('EXPLANATION: This is because this program causes a divide by
 zero,');
 writeln(' and interrupt vector type 0 is the divide error exception
 handler.');
 writeln('If you alter this program to do something else besides a divide');
 writeln(' by zero,you could use this program to try altering other
 interrupt');
 writeln(' vectors.  You can try entering other interrupt numbers into
 this');
 writeln(' program as it is, but the program will not execute the VECTIN');
 writeln(' procedure if you do.');
 write('Please enter an interrupt vector number  -->');
         read(hello);

 {******************************************************************
 ***** (4) FIRST YOU HAVE TO DISABLE INTERRUPTS USING DISBIN.     **
 *****     YOU THEN REPLACE THE EXISTING DIVIDE BY ZERO INTERRUPT **
 *****     HANDLER WITH YOUR PREFERRED PROCEDURE USING VECTIN.    **
 *****     YOU THEN ENABLE INTERRUPTS AGAIN, USING ENABIN.        **
 *******************************************************************
 ***** IMPORTANT NOTE: THIS IS A SIMPLE PROGRAM AND DOES NOT SAVE **
 ***** THE ORIGINAL ZERO INTERRUPT HANDLER                        **
 *******************************************************************}

         DISBIN;
         VECTIN(hello,world);
         ENABIN;

 {******************************************************************
 ***** (5) THIS PERFORMS A DIVIDE BY ZERO, WHICH WILL CAUSE THE ****
 *****     "world" PROCEDURE TO BE EXECUTED.                    ****
 *******************************************************************}

         VAR1 := 1;
         WRITELN('VAR1 := 1');
         ZERO := 0;
         WRITELN('ZERO := 0');
         writeln('var1 / zero = ...');
         writeln(' ');
         VAR2 := var1 div zero;
 End.


 42. VECTIN Procedure

 Product Version(s): 3.20 3.3x
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 19-FEB-1988    ArticleIdent: Q10288

 Question:
    The Microsoft Pascal reference manual, Version 3.20,
 Page 271, says (concerning the VECTIN procedure) to see
 Appendix B, "Version Specifics," in the Microsoft Pascal
 Compiler user's guide for information regarding
 implementation. However, there is no notation in Appendix B
 regarding implementation.
    Do we need to make an adaptation to have the VECTIN
 procedure work properly? Explain the statement "...the
 meaning of [argument] V varies with target machine".

 Response:
    "Implementation" as it is used in Appendix B refers to
 this version of Pascal. So, "implementation additions"
 means additions to the previous implementation, i.e.,
 changes to Microsoft Pascal Version 3.20 which were not
 included in Version 3.13. In Appendix B, there is a great
 deal of information regarding this implementation.
    No adaptation is necessary to get VECTIN to work. It
 either works or it does not, and in Versions 3.20 to 3.32
 it does work.
    "The effect of these procedures and the meaning of V
 varies with the target machine," simply means that
 interrupt vectors are hardware specific. The effect of
 changing the interrupt vector 2 on an IBM Personal Computer
 could be extremely different from the effect of changing
 interrupt vector 2 on the Siemens PC, and you need to know
 what the difference is to use this VECTIN procedure.


 43. GTYUQQ Function Reads One Character Less Than Maximum

 Product Version(s): 3.13 3.20 3.3x
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist3.13 buglist3.20 fixlist3.30
 Last Modified: 19-FEB-1988    ArticleIdent: Q10358

 Problem:
    The GTYUQQ function will only read characters up to one
 less than the maximum specified. For example, if the
 maximum specified was 10 then the GTYUQQ function will only
 read up to nine characters.

 Response:
    This problem was corrected in Version 3.30.


 44. Altering the Stack Size

 Product Version(s): 3.3x
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 26-SEP-1988    ArticleIdent: Q10377

 Question:

 How can I adjust the size of a program's run-time stack with Pascal
 Version 3.3x?

 Response:

 You may use the /STACK linker option using the following command:

 link /STACK:<number> <object_file_name>;

 The <number> will be the decimal number of bytes for the size of the
 program's stack; <number> should be greater than 0 and less than
 64,000.

 Try to keep the stack size between 2000 and 30,000 bytes. A stack of
 64,000 could interfere with near-heap allocation, which also occurs in
 the same 64K default data segment. (The note of warning in the
 "Microsoft Pascal Compiler User's Guide" concerning the /STACK linker
 switch applied to Pascal Version 3.20, and is no longer a problem in
 Versions 3.3x.)

 Alternately, the EXEMOD utility can be used to change the stack
 size of a program after it has been linked, as in the following:

 exemod <exe_name> /stack <hex_number>

 The <exe_name> is the name of your executable file; <hex_number>
 specifies the hexadecimal number of bytes in the stack.


 45. Byte Comparison Causes PAS2 of Pascal Version 3.20 to Hang

 Product Version(s): 3.20
 Operating System:   MS-DOS
 Flags: ENDUSER | TAR17016 buglist3.20 fixlist3.30
 Last Modified:  3-OCT-1988    ArticleIdent: Q10378

 Problem:

 This problem involves byte comparisons and common subexpressions,
 i.e., if one of the elements of the comparison ends up in an index
 register because of an earlier subexpression, PAS2 would infinitely
 loop. The following program hangs in PAS2:

 SHORT EXAMPLE CODE:

    PROGRAM TEST(INPUT,OUTPUT);
    CONST UC_A=ORD('A');
    UC_Z=ORD('Z');
    VAR BUFF : ARRAY[0..255] OF CHAR;
    I, N : INTEGER;
    BEGIN
    FOR I:=UC_A TO UC_Z DO
    IF BUFF[I] <> CHR(I) THEN
    N:=SUCC(N);
    IF I<>N THEN
    N:=SUCC(N)
    END.

 Response:

 If an ORD function is added to the buff[i] in the comparison, the
 program compiles.

 Microsoft has confirmed this to be a problem in Version 3.20. This
 problem was corrected in Version 3.30.


 46. Calling Functions with Var Parameters

 Product Version(s): 3.20
 Operating System:   MS-DOS
 Flags: ENDUSER | TAR15705 buglist3.20 fixlist3.30
 Last Modified:  3-OCT-1988    ArticleIdent: Q10379

 Problem:

 The program shown below exhibits a problem when calling transcendental
 functions with var parameters. The address is improperly set for the
 argument that was defined as a formal reference (var) parameter.

 The following is a short code example:

    program fu(output);
    var  X : real8;

    PROCEDURE A1(VAR T: real8);
    begin
       T := exp(T)
    end;

    begin
       X := 1.0;
       A1(X);
       writeln('X = ',X)
    end.

 Response:

 Microsoft has confirmed this to be a problem in Version 3.20. This
 problem was corrected in Version 3.30.


 47. Searching for $INCLUDE Files

 Product Version(s): 3.20 3.3x
 Operating System:   MS-DOS
 Flags: ENDUSER | TAR17161
 Last Modified: 19-FEB-1988    ArticleIdent: Q10380

 Question:
    Can Version 3.20 of the Microsoft Pascal compiler use
 the $INCLUDE metacommand to bring in text from other
 directories? We cannot get this procedure to work properly
 and we do not want all of our interfaces in the same
 directory where the program is being written.

 Response:
    No, the Version 3.20 compiler uses the DOS Version 1.x
 compatible file system (i.e., no hierarchical file
 structure). Hence, the compiler can only find files that
 reside in the current directory.
    However, in Pascal Version 3.3x you are able to use path
 names because the compiler uses the DOS Version 2.x file
 system which does support non-root directories.


 48. Must Use readln to Read End of Text Line

 Product Version(s): 3.20 3.3x
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified:  3-OCT-1988    ArticleIdent: Q10381

 Question:

 The file READ.PAS is an example of a program that uses a read
 statement to input the value of an lstring variable. The program loops
 indefinitely after the first value is read and written. Replacing the
 read with a readln causes the program to run as I would expect. Why
 does this occur?

 Is the read statement unable to read past the end of a line of text
 when reading an lstring value? This problem also occurs with string
 variables. The following READ.PAS program is an example:

    program read_lstring(input,output);
    VAR s : lstring(6);
    begin
    repeat
    write('enter string > ');
    read(s);
    writeln(s)
    until (s = 'bye');
    end.

 Response:

 You must use readln to read past the end-of-line marker for a text
 file. The files INPUT and OUTPUT, declared in the program statement,
 are text files.

 INPUT and OUTPUT are wholly distinct as far as Pascal is concerned.
 Thus, the fact that an intervening writeln (or two) may have advanced
 the line on the console device has no effect on the reads.

 All reads will take their data from the 80 character INPUT file buffer
 until there is an intervening readln. Because read(s), where "s" is an
 lstring variable, is satisfied with null input, you can have
 infinitely many consecutive read(s)s.

 Note: using readln (and writeln) only applies to text files. Other
 files defined by the type statement "file of <type>;" do not have
 end-of-line markers to be read/written by readln/writeln.


 49. Var Formal Parameters Ignore String Lengths

 Product Version(s): 3.20 3.3x
 Operating System:   MS-DOS
 Flags: ENDUSER | TAR15372
 Last Modified:  3-OCT-1988    ArticleIdent: Q10382

 Question:

 Why does PAS1 fail to detect the type mismatch between
 formal and actual lstring parameters of different lengths
 in the following code?

    PROGRAM TEST_LSTRINGS(INPUT,OUTPUT);
    TYPE
    LONGTYPE=LSTRING(200);
    SHORTTYPE=LSTRING(10);
    VAR
    SHORTSTR:SHORTTYPE;

    PROCEDURE DUMMY(VAR LONG:LONGTYPE);
    VAR LOCLONG:LONGTYPE;
    BEGIN
    LOCLONG:='1234';
    LONG:=LOCLONG;
    END;

    BEGIN {MAIN}
    DUMMY(SHORTSTR);
    END.

 Response:

 Because the formal parameter of procedure dummy is declared to be of
 type lstring (200), a type-mismatch error might be expected when dummy
 is called with the actual parameter shortstr, which is a lstring of
 length 10.

 However, type checking in this case is explicitly disabled (and has
 been for a long time, through many releases). Passing strings and
 lstrings by reference using var or vars ignores the string lengths. As
 a result, you are given the flexibility of using the same function or
 procedure to process strings of different lengths.


 50. Error 312 when Using the Variable Plm

 Product Version(s): 3.20
 Operating System:   MS-DOS
 Flags: ENDUSER | TAR02497 buglist3.20 fixlist3.30
 Last Modified:  3-OCT-1988    ArticleIdent: Q10384

 The declaration of plm causes pas1 to emit a compile-time error 312
 "identifier expected."

 The following is a short example code:

    program test(input,output);
    var PLM:integer;
    begin
    end.

 Microsoft has confirmed this to be a problem in Version 3.20. This
 problem was corrected in Version 3.30.

 In Version 3.20, plm was used as a procedure attribute to specify
 calling conventions and was incorrectly treated as a reserved word. In
 Version 3.30, plm may be redefined.


 51. Goto with {$line+} Gives Error 293

 Product Version(s): 3.20 3.3x
 Operating System:   MS-DOS
 Flags: ENDUSER | TAR17029
 Last Modified: 30-SEP-1988    ArticleIdent: Q10386

 According to Page 171 of the "Microsoft Pascal Compiler for the MS-DOS
 Operating System Reference Manual," a goto from a procedure to a
 higher-level procedure is permitted, although it is considered
 harmful.

 However, the code below generates the "error 293 - Goto invalid"
 message at compile time. If the {$line+} metacommand is removed, then
 the message is not generated.

 This error message occurs because if debugging is on (invoked by
 {$line+}), a procedure entry and exit code is generated. The exit code
 is bypassed by the goto, and from then on error recovery is corrupted.

 The following is a short code example:

    {$LINE+}
    PROGRAM TEST(INPUT,OUTPUT);
    LABEL 99;

    PROCEDURE A;
    BEGIN
    GOTO 99;
    END;

    BEGIN {MAIN}
    A;
    99:WRITELN('AT LABEL 99');
    END.


 52. Heap Space Not Freed When a File is Closed

 Product Version(s): 3.20
 Operating System:   MS-DOS
 Flags: ENDUSER | TAR15365 buglist3.20 fixlist3.30
 Last Modified: 19-FEB-1988    ArticleIdent: Q10387

 Problem:
    The "assign" statement allocates file information on the
 heap. When the file is closed, the space allocated is not
 returned to the heap. When a "dispose" is used to close the
 file, the space allocated for the file information is
 returned to the heap.

 Response:
    This problem was corrected in Version 3.30.


 53. The High-Ordered Word Is Zeroed Out

 Product Version(s): 3.20
 Operating System:   MS-DOS
 Flags: ENDUSER | TAR50048 buglist3.20 fixlist3.30
 Last Modified: 30-SEP-1988    ArticleIdent: Q10388

 In the program below, improper code is generated for the multiply.
 After the multiply is performed, the high-order word is zeroed-out,
 indicating that the compiler is trying to do an unsigned coercion
 before assigning the value to a 4-byte integer.

 Microsoft has confirmed this to be a problem in Version 3.20. This
 problem was corrected in Version 3.30.

 The following is a short example code:

    program fu;
    VAR X : INTEGER4;
    W : WORD;
    BEGIN
    W := 50;
    X := W * 10000;
    END.


 54. References Off to Windows Procedure Variable in Version 3.20

 Product Version(s): 3.20
 Operating System:   MS-DOS
 Flags: ENDUSER | TAR09596 buglist3.20 fixlist3.30
 Last Modified: 20-OCT-1988    ArticleIdent: Q10389

 There is a problem in the following code with the statement "D31 := n
 + x". When attempting to reference a nested variable (x) of a Windows
 procedure, the offset of "x" is off by 2 bytes due to the Windows
 entry sequence that pushes DS before allocating local memory.

 Microsoft has confirmed this to be a problem in Version 3.20. This
 problem was corrected in Version 3.30.

 The following is a short example code:

     {$stackseg+}
     module death;
     type
        deaths_head=record
          X,Y:integer;
          DATA:lstring(255);
          end;

     PROCEDURE D1(D:deaths_head)[public,windows];
     begin
       D.X:=d.y;
     end;

     procedure d2[public,windows];
     VAR DX:deaths_head;
     begin
       d1(dx);
     end;

     procedure d3[public,windows];
     VAR X:integer;
         FUNCTION D31(N:integer):integer;
         begin
            D31:=n+x;
         end;
     begin
       X:=5;
       X:=d31(10);
     end;
     end. {module death}


 55. Laddok Does Not Prevent Overflows

 Product Version(s): 3.20 3.3x
 Operating System:   MS-DOS
 Flags: ENDUSER | TAR05457
 Last Modified: 30-SEP-1988    ArticleIdent: Q10390

 Problem:

 The no-overflow addition function for integer4 numbers (laddok) does
 not handle adding 1 to the maximum positive integer4 number
 (2,147,483,647). The program crashes when this procedure is attempted.
 The correct result for laddok(2147483647,1) is the minimum negative
 integer4 number (-2,147,483,647). The calculation laddok(2147483647,2)
 does produce the result -2,147,483,647. The following is a short
 example code:

    program RollOver(input, output);
    VAR k: integer4;
    FUNCTION LADDOK(A, B: integer4; var c: integer4): boolean; extern;
    begin
    writeln('Rollover Test');
    writeln;

    if laddok(2147483647, 2, k) then
    WRITE('NO OVERFLOW: ')
    else
    WRITE('OVERFLOW: ');
    writeln('Result = ',k);

    if laddok(2147483647, 1, k) then
    WRITE('NO OVERFLOW: ')
    else
    WRITE('OVERFLOW: ');
    writeln('Result = ',k)
    end.

 Response:

 The behavior of the example program is entirely correct; your
 diagnosis is incorrect.

 The result of laddok(2147483647,1,k) is 16#80000000, which is not a
 valid integer4 value. Laddok permits you to carry out this add without
 getting a fatal run-time error. However, there is no way to keep
 write/writeln from discovering that variable "k" has this invalid
 value in the subsequent "writeln('Result = ',k);". It is this attempt
 to write out the illegal value that is causing the run-time error. You
 can get the same error by setting "k := 16#80000000" and then trying a
 "write(k)".


 56. lmulok Allows Overflow, but Gives No Message

 Product Version(s): 3.20 3.3x
 Operating System:   MS-DOS
 Flags: ENDUSER | TAR50110 docerr
 Last Modified: 18-AUG-1988    ArticleIdent: Q10393

 Problem:
    The program fragment below demonstrates a problem with the lmulok
 function. The value the function returns is correct. However, if you
 try to write out the value of the product when lmulok returns false,
 you get a data-format error at run time.
    The following is an example of input that causes the error:

    first integer4 >2000000
    second integer4 >2000000

    Notice that the multiplication is done without any errors, but
 writing out the product causes a data format error.
    Also, note that the behavior of lmulok is specified in the
 reference manual. I examined the example with SYMDEB and found that
 whenever the multiplication overflows, lmulok sets the value of the
 product to 16#80000000, i.e., (unsigned) 2^31. Of course, 16#80000000
 is not a legal integer4 value.
    The following is a short example code:

    program xx(input,output);
    VAR I,J,PRODUCT : integer4;
    X : integer;
    RESULT : boolean;
    FUNCTION LMULOK(A,B:integer4; var c:integer4) : boolean; extern;
    begin
    writeln;
    write('first integer4 >');
    readln(i);
    write('second integer4 >');
    readln(j);
    RESULT := lmulok(i,j,product);
    WRITELN(I:20,j:20);
    writeln(product);
    WRITELN('RESULT = ',RESULT:5)
    end.

 Response:
    This problem is the result of a documentation error on Page 240 of
 the Version 3.32 "Microsoft Pascal Compiler Reference Manual."
    The routine lmulok is the routine ultimately called to perform the
 multiplication in any integer4 product, e.g. the code generated for I
 := J * K;, where I,J,K:integer4, will invoke lmulok. You are given
 access to this routine so you can perform an integer4 multiplication,
 which overflows without having the program abort with a fatal run-time
 error.
    The value of the product is well defined only in the case where the
 product does not overflow, i.e., the return value of lmulok is true.
 This process occurs because the overflow condition is generally
 detected before the multiplication is complete and computation ceases
 as soon as the overflow is detected. The documentation indicates that
 the product is always computed and returned; this is clearly
 incorrect.


 57. Out of Memory Error in PAS2

 Product Version(s): 3.20
 Operating System:   MS-DOS
 Flags: ENDUSER | TAR17019 buglist3.20 fixlist3.30
 Last Modified: 20-OCT-1988    ArticleIdent: Q10395

 The following example yields an out-of-memory error in PAS2 of the
 compiler. If buff_ads is declared to be of adr type rather than ads
 type, the program will then compile the code below.

 Microsoft has confirmed this to be a problem in Version 3.20. This
 problem was corrected in Version 3.30.

 The following code demonstrates the problem:

    program test(input, output);
    type
    buff_rec = record
    BUFF1_PTR:adrmem;
    end;
    var
    BUFF_ADS:ads of buff_rec;
    BUFF1:lstring(50);
    BUFF2:lstring(50);
    LOC:word;
    TMP_ADR:adrmem;
    begin
    with buff_ads^ do
    begin
    BUFF1:='1234it worked!';
    LOC:=5;
    BUFF1_PTR:=adr buff1;
    TMP_ADR:=adr buff1_ptr^[loc];
    movel(adr buff1_ptr^[loc],adr buff2[1],10);
    movel(tmp_adr,adr buff2[1],10);
    BUFF2[0]:=chr(10);
    writeln;
    writeln('********p3582');
    writeln;
    writeln(buff2);
    end;
    end.


 58. PAS1 Loops Infinitely if Too Many Errors

 Product Version(s): 3.13 3.20
 Operating System:   MS-DOS
 Flags: ENDUSER | TAR07491 buglist3.13 buglist3.20 fixlist3.30
 Last Modified: 16-DEC-1987    ArticleIdent: Q10396

 Problem:
    Under Version 3.13 of the Pascal compiler, when the
 number of syntax errors encountered by PAS1 exceeds the
 amount specified with the $errors metacommand, PAS1 loops
 infinitely. Under Version 3.20, PAS1 emits the error
 message "error count exceeded - compiler cannot continue"
 repeatedly until the compiler runs out of memory.

 Response:
    This behavior was caused because the procedure called
 when the number of errors overflows ("panic") attempts to
 flush the listing file by successively calling the lexer.
 Since the lexer can generate errors, rampant recursion is
 triggered. The Pascal front end (PAS1) was changed to avoid
 this recursion in Version 3.30.


 59. Problem with Assigning the Chr of a Trunc

 Product Version(s): 3.13 3.20
 Operating System:   MS-DOS
 Flags: ENDUSER | TAR15705 buglist3.20 fixlist3.30
 Last Modified: 16-DEC-1987    ArticleIdent: Q10397

 Problem:
    Assigning the chr of a trunc generates a two byte value
 overwriting the target string. The following is a short
 example code:

    program b(input,output);

    procedure b1;
    var
    I: integer;
    S: string(8);
    begin {b1}
    S := 'QQQQQQQQ';
    FOR I := 1 to 8 do
    begin
    S[I] := chr(trunc(80.0));
    WRITELN('I = ',I:0,' s = ',s)
    end
    end; {b1}

    begin {b}
    b1
    end. {b}

 \.BODYTEXT
 Response:
    PAS2 was performing an optimization which was
 eliminating the coercion node on assignment trees.
    This problem was corrected in Version 3.30.


 60. Problem Passing Function as CONST Parameter in Version 3.20

 Product Version(s): 3.20
 Operating System:   MS-DOS
 Flags: ENDUSER | TAR17011 buglist3.20 fixlist3.30
 Last Modified: 30-SEP-1988    ArticleIdent: Q10398

 The examples below exhibit two problems trying to pass functions as
 CONST parameters. In the first example when the function F is enclosed
 in a parenthesis in the "copystr" call, it appears as if F is invoked
 twice. When the parenthesis is omitted as in the second example, PAS1
 emits a compile time error 227 - Invalid address of Function.

 Microsoft has confirmed this to be a problem in Version 3.20. This
 problem was corrected in Version 3.30.

 The example code as is as follows:

 Example 1

     PROGRAM PAREN(INPUT,OUTPUT);
        TYPE LSTR_80=LSTRING(80);
        VAR  B_STRING:STRING(4);

        FUNCTION F:LSTR_80;
           BEGIN
            WRITELN('INSIDE FUNCTION F');
            F:='1234';
           END;

     BEGIN {MAIN}
       COPYSTR((F),B_STRING);
       WRITELN(B_STRING);
     END.

 Example 2

     PROGRAM PAREN(INPUT,OUTPUT);
        TYPE LSTR_80=LSTRING(80);
        VAR  B_STRING:STRING(4);

        FUNCTION F:LSTR_80;
           BEGIN
            WRITELN('INSIDE FUNCTION F');
            F:='1234';
           END;

     BEGIN {MAIN}
       COPYSTR(F,B_STRING);
       WRITELN(B_STRING);
     END.


 61. Problems Using NULE6

 Product Version(s): 3.20
 Operating System:   MS-DOS
 Flags: ENDUSER | TAR17162
 Last Modified: 16-DEC-1987    ArticleIdent: Q10399

 Question:
    When we link in the modules NULE6 and NULF with our MS
 Pascal programs, we get an error at link time specifying
 that certain "QQ" symbols are defined twice. How can we
 eliminate unneeded error checking and file routines so that
 we can reduce the size of the program? What other types
 of routines also can be eliminated to reduce this size?

 Response:
    Please refer to the discussion in the user's guide
 (Section 8.5).
    Your unexpected need for NULE6.OBJ may be caused by the
 use of initialized units (see paragraph 2 of subsection
 8.5.2).


 62. Problems with Segmented Address Types

 Product Version(s): 3.20
 Operating System:   MS-DOS
 Flags: ENDUSER | TAR50072 buglist3.20 fixlist3.30
 Last Modified: 20-OCT-1988    ArticleIdent: Q10401

 There is a problem with address types and long-heap allocation. The
 code below contains the constant declaration "const newnil=ptr(0,0)"
 and uses it in an if statement. The program should execute the else
 part of the if statement and print out that "t^.nest^.back" and t are
 equal. However, instead of executing the else part of the if statement
 (so it would think the addresses are different), the program prints
 out that the addresses are the same.

 Microsoft has confirmed this to be a problem in Version 3.20. This
 problem was corrected in Version 3.30.

 The following is the short sample code:

    program test(input,output);
    type ptr = ads of word;
    p_somestruct = ads of somestruct;
    somestruct = record
    NEXT:p_somestruct;
    BACK:p_somestruct;
    end;
    const newnil = ptr(0,0);
    VAR t : p_somestruct;

    FUNCTION GETMQQ(WANTS : word) : adsmem; extern;

    begin
    t := getmqq(sizeof(t^));
    t^.next := getmqq(sizeof(t^.next^));
    t^.next^.back := t;
    if t^.next <> newnil then
    if t^.next^.back <> t then
    begin
    writeln('test says T^.NEXT^.BACK and T are not equal, BUT...');
    writeln('T^.NEXT^.BACK=',T^.NEXT^.BACK.S,T^.NEXT^.BACK.R);
    WRITELN('T =',t.s,t.r);
    end
    else
    writeln('T^.NEXT^.BACK and T are equal');
    end.


 63. Linking in DOS2PAS.LIB Versus PASCAL.LIB

 Product Version(s): 3.20
 Operating System:   MS-DOS
 Flags: ENDUSER | TAR17027
 Last Modified: 30-SEP-1988    ArticleIdent: Q10402

 Question:

 When the following program is linked with the DOS2PAS.LIB, it behaves
 differently than when linked with just the PASCAL.LIB (which has the
 DOS Version 1.x I/O package).

 When linked with the DOS Versions 2.x I/O package DOS2PAS.LIB, the
 program seems to lag one character behind. When the "f.mode :=
 terminal;" is omitted, similar behavior is experienced. What is the
 difference between terminal I/O and sequential binary mode?

 The following is a short example code:

    PROGRAM xx(input,output);
    VAR C : char;
    F : file of char;
    BEGIN
    assign(f,'con');
    F.MODE := terminal;
    reset(f);
    writeln('end program with an "@"');
    while c<>'@' do begin
    read(f,c);
    if (c <> chr(0)) then begin
    write(c);
    writeln(ord(c))
    end
    end
    END.

 Response:

 No corrective action needs to be taken. The test programs are geared
 to DOS Version 1.25. DOS Version 1.25 uses a polling model for console
 I/O. If no input is in the queue DOS returns a 0. Thus, the line "if
 chr(c) <> 0" skips over calls that returned no input. DOS Versions
 2.0x use a different method, e.g. wait for input. Because the test is
 geared for DOS Version 1.25, the DOS Version 2.00 release always seems
 to be one character behind.

 For information about the difference between terminal and sequential
 mode, see Section 8.4 of the "Microsoft Pascal Compiler Reference
 Manual."

 Note: in the Version 3.30 release, only the DOS Versions 2.x I/O
 interface will be supported.


 64. Nil Not Equal to Zero

 Product Version(s): 3.20
 Operating System:   MS-DOS
 Flags: ENDUSER | TAR17028 buglist3.20 fixlist3.30
 Last Modified: 30-SEP-1988    ArticleIdent: Q10403

 Question:

 Super array pointers allocate words to hold the upper bound of the
 allocated type. In the following program, the word following the
 pointer holds the upper bound. When nil is assigned to pointer, the
 value of 0 is assigned to the pointer, and 2 is assigned to the upper
 bound portion. Why is 2 assigned and why not 0 also?

 The following is the short example code:

    program test(input,output);
    type hundred=lstring(99);
    supar =super array[1..*] of hundred;
    VAR POINTER:^supar;
    Y :word;
    begin
    POINTER:=nil;
    Y:=sizeof(pointer^,20);
    writeln('size returned =',y);
    end.

 Response:

 Microsoft has confirmed this to be a problem in Version 3.20. This
 problem was corrected in Version 3.30.


 65. Local Record Passed Incorrectly with {$stackseg+}

 Product Version(s): 3.20
 Operating System:   MS-DOS
 Flags: ENDUSER | TAR09596 buglist3.20 fixlist3.30
 Last Modified: 20-OCT-1988    ArticleIdent: Q10405

 There are problems with a string move when the source and target are
 both on the stack. Incorrect code is generated for passing a stack
 item as a value parameter with the {$stackseg+} metacommand in effect.
 The problem occurs at the procedure call statement "d1(dx)", and
 involves a string move where the source and target are both on the
 stack. The code generated assumes that both source and target are
 resident in dgroup (ds relative).

 This assumption is false when $stackseg is enabled.

 Microsoft has confirmed this to be a problem in Version 3.20. This
 problem was corrected in Version 3.30.

 The following is a short example program:

    {$stackseg+}
    module death;
    type
    deaths_head=record
    X,Y:integer;
    DATA:lstring(255);
    end;

    PROCEDURE D1(D:deaths_head)[public,windows];
    begin
    D.X:=d.y;
    end;

    procedure d2[public,windows];
    VAR DX:deaths_head;
    begin
    d1(dx);
    end;

    procedure d3[public,windows];
    VAR X:integer;
    FUNCTION D31(N:integer):integer;
    begin
    D31:=n+x;
    end;
    begin
    X:=5;
    X:=d31(10);
    end;
    end.


 66. Redirected Input File Causes Run-Time Hang

 Product Version(s): 3.13 3.20 3.3x
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 30-SEP-1988    ArticleIdent: Q10406

 Problem:

 Using the ::N notation to write an integer causes a run-time error. We
 used the ::N notation to write an integer with a radix other than 2,
 8, 10, or 16. This procedure causes a data-format error in the file
 USER at run time.

 The following is sample code:

    program wformats(input,output);
    var
    I:integer;
    begin
    I:=32;
    WRITELN(I::3);
    end.

 Response:

 MS-DOS does not return an end-of-file from a redirected input file
 when it runs out of text; DOS just hangs. This problem has nothing to
 do with Pascal.

 Put a ^Z (CTRL+Z), or chr(26) in the file and it will work
 properly.


 67. Referencing Origin from Other Module or Unit

 Product Version(s): 3.20
 Operating System:   MS-DOS
 Flags: ENDUSER | TAR17015 buglist3.20 fixlist3.30
 Last Modified: 30-SEP-1988    ArticleIdent: Q10408

 Problem:

 In the following examples, I am trying to reference variables with the
 origin (segmented address) attribute across compilation modules.
 However, both fail to pass the origin. In the first example, I attempt
 to use the unit/interface method; in the second example, I am
 trying to reference the origin via modules with public/external
 variables. The only way that I can successfully reference origin
 variables across compilation units is to declare the variables with
 matching-origin attributes in each compilation unit.

 The following is a short sample code:

 Example 1

    {$INCLUDE: 'yu.int'}
    program x(input,output);
    uses y;
    begin
    I := 13;
    subcall;
    WRITELN('FROM MAIN PROGRAM I, J AND K ARE: ', i:8, j:8, k:8);
    end.

    {$INCLUDE: 'yu.int'}
    implementation of y;
    procedure subcall;
    begin
    J := 33;
    WRITELN('USING SUBCALL: i, j and k are: ', i:8, j:8, k:8);
    end;

    begin
    K := 53;
    end.

    interface;
    unit y(i, j, k, subcall);
    var
    I[ ORIGIN 16#6000 : 16#0000 ] : integer;
    J [ ORIGIN 16#6001 : 16#0000 ] : integer;
    K [ ORIGIN 16#6002 : 16#0000 ] : integer;
    procedure subcall;
    begin
    end;

 Example2

    program x(input,output);
    VAR [EXTERN] I, J, K : integer;
    procedure subcall;extern;
    begin
    I := 13;
    subcall;
    WRITELN('FROM MAIN PROGRAM I, J AND K ARE: ', i:8, j:8, k:8);
    end. {program x}

    module y;

    VAR I [PUBLIC,ORIGIN 16#6000:0000] : integer;
    J [PUBLIC,ORIGIN 16#6001:0000] : integer;
    K [PUBLIC,ORIGIN 16#6002:0000] : integer;

    procedure subcall;
    begin
    J := 33;
    K := 53;
    WRITELN('USING SUBCALL: i, j and k are: ', i:8, j:8, k:8);
    end;

    end. {module y}

 Response:

 The above examples actually constitute two completely separate
 problems.

 In Example 1, the variables are being allocated when the interface
 was processed. They then were reallocated when the implementation was
 processed and the origin forgotten.

 Microsoft has confirmed this to be a problem in Version 3.20. This
 problem was corrected in Version 3.30.

 In Example 2, external variables are assumed to be in "ds"; there
 is no way, in the examples, to indicate that they are origined (this
 cannot work correctly). Versions 3.3x of the compiler will not allow
 specification of origin and extern on the same object. However, simply
 making them static will work properly because the actual address is
 being explicitly specified.

 If you want to access origined variables using the unit/interface
 route, it is suggested that all origined variables be declared as such
 in each module with matching allocation specifications. This procedure
 can be easily accomplished by using the $include file facility.


 68. Unresolved External: avlgqq

 Product Version(s): 3.20
 Operating System:   MS-DOS
 Flags: ENDUSER | TAR50138 buglist3.20 fixlist3.30
 Last Modified: 30-SEP-1988    ArticleIdent: Q10409

 Problem:

 The following program compiles successfully, but generates the
 unresolved external "avlgqq" at link time. The following is a short
 example code:

    PROGRAM TEST(INPUT,OUTPUT);
    TYPE RTYPE=(TYPE1,TYPE2);
    RECTYPE=RECORD
    CASE T:RTYPE OF
    TYPE1:(UDEF:INTEGER);
    TYPE2:(FID:REAL);
    END;
    VAR ADS_REC:ADS OF RECTYPE;
    PTR_REC:^RECTYPE;
    BEGIN
    NEW(PTR_REC);
    PTR_REC^:=ADS_REC^;
    END.

 Response:

 The avlgqq external is a routine to move a variable number of bytes
 from a segmented address to the heap. It appears that there has not
 actually been such a routine in the library for quite a while. An
 avlgqq routine has now been written and placed in the PASCAL.LIB for
 Versions 3.30 and later.

 Microsoft has confirmed this to be a problem in Version 3.20. This
 problem was corrected in Version 3.30.


 69. sizeof Ignores Upper Bound of Super Array

 Product Version(s): 3.20
 Operating System:   MS-DOS
 Flags: ENDUSER | TAR17010 buglist3.20 fixlist3.30
 Last Modified:  4-OCT-1988    ArticleIdent: Q10410

 Problem:

 When discussing the sizeof statement, the "Microsoft Pascal Compiler
 for the MS-DOS Operating System Reference Manual" states that "if the
 variable is a super array, the second form, which gives upper bounds,
 must be used."

 In the example program below, the second parameter of the sizeof call
 is ignored. The upper bound of the allocated pointer is stored in the
 second word of the pointer value. When the sizeof function is invoked,
 the value stored in the second word of the super array pointer is used
 to calculate the size of the super array pointer. However, when the
 second parameter is omitted from the sizeof call, PAS1 emits a compile
 time error 233 "invalid procedure or function parameter."

 The following is the short example code:

    program test(input,output);
    type hundred=lstring(99);
    supar =super array[1..*] of hundred;
    VAR POINTER:^supar;
    Y :word;
    begin
    new(pointer,20);
    Y:=sizeof(pointer^,10);
    writeln('size returned =',y);
    end.

 Response:

 This behavior has been changed by adding the ability to use the short
 form of sizeof on a short array pointer. The long form now returns the
 length calculated purely from the values specified in the sizeof call,
 and ignores the fields in the pointer. The short form uses only the
 pointer fields.

 Microsoft has confirmed this to be a problem in Version 3.20. This
 problem was corrected in Version 3.30.

 Note: a feature, sizeof(p^), has been added where p is a pointer to a
 super array. Now, this is a valid expression but it is the
 programmer's responsibility to ensure that p^ has been allocated. Also
 note that if p = pointer to a one-dimensional super array then
 sizeof(p^, 10) depends only on the underlying type of the super array
 and 10. Whether or not p^ has been allocated is irrelevant.


 70. Warning for Label Following Hex Number

 Product Version(s): 3.20
 Operating System:   MS-DOS
 Flags: ENDUSER | TAR50109 buglist3.20 fixlist3.30
 Last Modified: 30-SEP-1988    ArticleIdent: Q10412

 Problem:

 The following program fragment contains an example of an integer label
 following a hex number (16#30). This causes the PAS1 compiler message
 "Warning 280 Invalid Integer Label" to be generated. If any statement
 is included between the two statements, no warning statement is
 generated.

 The following is a short example code:

    program xx(input,output);
    label 10;
    VAR dummy,HEXNUM : word;

    PROCEDURE HEY(VAR OOPS : word); extern;

    begin
    HEXNUM := 16#30;
    10: HEY(dummy);
    if (dummy<>0) then goto 10;
    end.

 Response:

 In the case above, a flag remains set that indicates the
 number 10 is in hex radix. Because the hex radix is not legal
 in numeric labels, a warning is emitted.

 Microsoft has confirmed this to be a problem in Version 3.20. This
 problem was corrected in Version 3.30.


 71. Working Around Lack of MARKAS and RELEAS

 Product Version(s): 3.20 3.3x
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 23-FEB-1988    ArticleIdent: Q10413

 Question:
    The MARKAS and RELEASE procedures do not function correctly in
 Version 3.20, and will not be included in 3.3x versions. We have got a
 workaround for our product that uses the ALLMQQ and FREMQQ procedures
 instead. Do these procedures work correctly, and will they be
 supported in future releases of Microsoft Pascal?

 Response:
    Yes the ALLMQQ and FREMQQ procedures do work in 3.3x, and we do
 plan to provide support for them in the future.
    It is entirely possible to use ALLMQQ/FREMQQ to implement some sort
 of heap management. However, if these could be used to easily
 implement the functional equivalent of MARKAS and RELEAS then we would
 still be supporting MARKAS and RELEAS in 3.3x (i.e., these function
 were dropped because it was determined that they did not work
 correctly and there was no good way to make them work correctly with
 our heap implementation). You should review the heap management used
 in Version 3.3x to see what effects this may have on your particular
 implementation.


 72. ".R" Field in ADS Variable Incorrectly Assigned

 Product Version(s): 3.30 3.31
 Operating System:   MS-DOS
 Flags: ENDUSER | TAR51446 buglist3.30 fixlist3.31
 Last Modified: 30-SEP-1988    ArticleIdent: Q10813

 With MS-DOS Pascal Version 3.30, the ".R" field of an ADS variable can
 be incorrectly assigned. The assignment is incorrect if it is made as
 follows:

 (ADS OF RECORD TYPE)^.FIELD.R:=(ads of record type).r
 (ADS OF RECORD TYPE)^.FIELD.S:=(ads of record type).s

 If a temporary ADS variable is used to hold the address of the
 allocated memory, the assignment is made correctly.

 Microsoft has confirmed this to be a problem in Version 3.30. This
 problem was corrected in Version 3.31.


 73. Programming the Mouse with Pascal

 Product Version(s): 3.3x
 Operating System:   MS-DOS
 Flags: ENDUSER | TAR51499
 Last Modified: 16-DEC-1987    ArticleIdent: Q10842

 Question:
    Are there any plans to support programming the mouse
 with Pascal?

 Response:
    There are no plans for including mouse specific
 instructions within the Microsoft implementation of
 Pascal.
    However, regarding making calls from a Pascal program to
 the mouse, that is possible and documented in the
 "Microsoft Mouse Programmer's Reference Guide" in the
 section "Making Calls From High-Level Languages". The mouse
 manual also contains information on making mouse system
 calls from BASIC and Assembly.


 74. Example Using the POSITN Function

 Product Version(s): 3.13 3.20 3.3x
 Operating System:   MS-DOS
 Flags: ENDUSER | TAR21065
 Last Modified: 30-SEP-1988    ArticleIdent: Q10853

 Question:

 I am trying to use the POSITN procedure without success. Could you
 give me an example that uses POSITN?

 Response:

 POSITN is an intrinsic function.

 The following example program demonstrates the use of the POSITN
 function:

    program position_ex(output);
    VAR     I        : integer;
            PAT      : string(3);
            S        : string(7);
            position : INTEGER;
    begin
       PAT:='pat';
       S:= 'pattern';
       I:= 1;
       position :=POSITN(PAT,S,I);
       WRITELN('POSITION=',position);
    end.

 The output was:    POSITION=             1


 75. {INTEGER:4} Not Supported in Versions 3.3x

 Product Version(s): 3.3x
 Operating System:   MS-DOS
 Flags: ENDUSER | TAR21447 docerr
 Last Modified: 18-AUG-1988    ArticleIdent: Q10861

 Problem:
    It is not clear whether the metacommand {$INTEGER:4} is still
 supported within PASCAL Version 3.3x. Page 318 in the "Microsoft
 Pascal Compiler Reference Manual" mentions this command, saying that
 you can use values 2 or 4 as arguments for the $integer metacommand.
    The index on Page 388 tells you that metacommand $integer is
 described on Pages 317 and 318. However, Table 18.2 on Page 317 does
 not show the metacommand.
    If you use {$integer:4}, the compiler gives you the following
 warning:

    Warning 116 Meta Value Out Of Range Skipped

    The Microsoft Pascal Compiler User's Guide states on Page 230 that
 only 2 is allowed as an argument for the $integer metacommand;
 {$INTEGER:4} will be ignored, producing errors in programs using this
 format.

 Response:
    {$INTEGER:4} is not supported in Versions 3.3x. These are
 documentation errors; only {$INTEGER:2} is supported.
    The documentation probably should not mention the metacommand because
 variables declared as type "integer" are two-byte integers, making the
 allowed form of this metacommand, {$integer:2}, redundant.


 76. VALUE Section Not Allowed with $ROM

 Product Version(s): 3.3x
 Operating System:   MS-DOS
 Flags: ENDUSER | TAR21824 docerr
 Last Modified: 26-SEP-1988    ArticleIdent: Q10862

 Pages 317 and 318 of the Pascal Reference Manual incorrectly state
 that using the $ROM metacommand in conjunction with the VALUE section
 results in a compiler warning; however, the metacommand, actually
 gives error message 347, "Cannot Use Value Section with ROM Memory."

 The manual should state that when you have a VALUE section in a
 program using the {$ROM+} metacommand, you will receive an error
 message.

 The following sample code demonstrates the problem:

 {$rom+}
 program xx;
 VAR   I :  integer;
 VALUE I := 1;
 begin
 end.


 77. Printing a File Containing CTRL+Z Characters

 Product Version(s): 3.3x
 Operating System:   MS-DOS
 Flags: ENDUSER | TAR21449
 Last Modified: 30-SEP-1988    ArticleIdent: Q10868

 Question:

 Printing fails when attempting to print out hexadecimal character 1A
 (CTRL+Z) with the following command:

 writeln(prn,chr(26));

 If written to the printer, you get "Error 1028 device full in file
 PRN". We used the following assignment to print CTRL+Z:

    VAR prn : text;
    begin
    assign(prn,'prn');
    rewrite(prn);
    writeln(prn,chr(26));

 Is this problem occurring because chr(26) is the end-of-file marker
 (CTRL+Z)? Can you eliminate this problem by using write or writeln?

 Response:

 This problem occurs because of the DOS interpretation of CTRL+Z, which
 is chr(26). When DOS is processing a file and encounters a CTRL++Z
 character, it interprets the CTRL+Z character as an
 end-of-file (EOF) marker.

 In your example, you are sending a file containing the CTRL+Z
 character to the printer. DOS interprets the character as the end of
 the file, causing anything after the CTRL+Z not to be printed. Pascal
 recognizes that it was not able to print out all that it should have
 and interprets that to mean that the printer was full. This behavior
 causes the "device full" error.

 The filename PRN is reserved by DOS for the printer device. Read,
 readln, write, and writeln all read/write data to/from textfiles. When
 you write a line to PRN (printer device) using writeln, you are trying
 to write a line of a textfile to the printer, as in the following
 example:

 writeln(prn,chr(26));

 Textfiles are files of type text and always have an ASCII structure.
 Because DOS always interprets CTRL+Z characters in ASCII files as
 EOF markers, DOS interprets this CTRL+Z as the EOF marker and quits.

 Thus, in Pascal and FORTRAN you cannot send CTRL+Z to either standard
 output (filename OUTPUT) or to the printer (filename PRN). If you
 were instead trying to send output to a binary file (FILE OF <type>),
 DOS would allow you to send a CTRL+Z.

 Do the following to work around this behavior of DOS:

 1. Ensure that your output contains only printable ASCII characters
    (this is the recommended method).

 2. Trap errors on output (PRN.TRAP := true) and then decide what to
    do when an error occurs, e.g. try to print a CTRL+Z. If
    you were using some other filename reserved by DOS (such as USER)
    with OUTPUT), you should write an assembler or MS-C routine to check
    that standard input/output has been redirected.

 3. Direct output to a file instead of to the printer or standard
    output. (Please note that this does not resolve your specific problem
    in which the objective is to print the CTRL+Z character at the
    printer device.)

 4. One other possibility is to put all of your data/characters into
    a binary (FILE OF <type>) file. This is a workaround for the DOS
    interpretation of a CTRL+Z character because DOS does not do any
    interpretation of a binary file; DOS only sends it on to the printer.
    Be careful if you use the binary-file approach because the compiler
    and DOS interpret the information contained in a binary file
    differently.

 In general, do the following:

 1. Make sure that output contains only printable ASCII characters.
    In particular, do not try to write a CTRL+Z to a TEXT file, i.e.,
    do not send a CTRL+Z to OUPUT, PRN, USER, etc.

 2. If you still want to be able to send a CTRL+Z to output, you
    must redirect output to a binary file or check for the CTRL+Z using
    error trapping.


 78. GETUQQ and PUTUQQ Fail Due to Buffered I/O

 Product Version(s): 3.3x
 Operating System:   Pascal
 Flags: ENDUSER | TAR21169
 Last Modified:  4-APR-1988    ArticleIdent: Q10880

 Question:
    There appears to be a problem with using getuqq() and seek()
 together on direct files. In each of the examples below, getuqq()
 appears to be returning values from the wrong position in the file
 after the first, or first few, seeks. The examples all work correctly
 with Version 3.20 (I linked with dos2pas.lib).
    Also, with the first two examples, calling rpsuqq() before each
 seek appears to solve the problem. However, the third example still
 malfunctions in this case.

 EXAMPLE 1:
 ----------
 {* This simple example was devised request to demonstrate the problem in
  * using seek() and getuqq() together in the case of a simple direct
  * file of char. If, instead of getuqq(), get() is used to fetch bytes from
  * the file, the program works correctly. The file sktst.dat is 28 bytes long
  * and consists of the characters 'A' through 'Z' followed by a carriage
  * return and line feed.
  *}
 program sktst(input, output);
 FUNCTION GETUQQ(VAR FFILE: fcbfqq; len: word; dst: adsmem): word; extern;
 VAR     I: word;
         C: char;
         F: file of char;
 begin
         F.MODE := direct;
         assign(f, 'sktst.dat');
         reset(f);
         FOR I := 10 downto 1 do begin
                 writeln;
                 writeln('i = ', i);
                 seek(f, i);
                 if getuqq(f, 1, ads c) <> 0 then
                         writeln('error! - getuqq failed!')
                 else if ord(c) <> (ord(i) + 64) then
                         writeln('error! - c = ', c)
                 else
                         writeln('correct character found');
         end
 end.

 CONTENTS OF SKTST.DAT:
 ---------------------
 ABCDEFGHIJKLMNOPQRSTUVWXYZ<cr><lf>

 ---------------------------------------------------------------------------

 EXAMPLE 2:
 ----------
 program bug (input,output);
 FUNCTION GETUQQ(VAR F : fcbfqq;
                  LEN : word;
                  DST : adsmem ) : word ; extern;
 const
   length = 6+2;
 VAR
   I : word;
   MSG : lstring(length);
   MSGFILE : file of char;
 Begin
   MSGFILE.MODE := direct;
   assign(msgfile,'bug.dat');
   reset(msgfile);
   if msgfile.errs = 0 then
     FOR I := 0 to 3 do begin
       seek(msgfile,length*i + 1);
       MSG.LEN := length - 2;
       if getuqq(msgfile,msg.len,ads msg[1]) <> 0 then
         MSG.LEN := 0;
       WRITELN(I:2,' ',msg);
     end;
 end.

 CONTENTS OF BUG.DAT:
 -------------------
 line 0<cr><lf>
 line 1<cr><lf>
 line 2<cr><lf>
 line 3<cr><lf>
 ^Z

 ---------------------------------------------------------------------------

 EXAMPLE 3:
 ----------
 {$INCLUDE:'finkxu'}
 {$INCLUDE:'finu'}
 program test(input,output);
 uses filuqq;
 uses filkqq;
 type    rec=record
                 I:integer;
                 S:string(230);
              end;
 VAR     DREC:rec;
         F:file of rec;
         I,IOSTATUS:word;
 begin
         writeln('size of drec=',sizeof(drec));
         F.MODE:=direct;
         assign(f,'this.dat');
         rewrite(f);
         FOR I:=1 to 10 do
          begin
           DREC.I:=ord(i);
           seek(f,i);
           IOSTATUS:=putuqq(f,sizeof(drec),ads drec);
          end;
         writeln('after for loop, i=',i);
         seek(f,1);
         FOR I:=1 to 10 do
          begin
            seek(f,i);
           IOSTATUS:=getuqq(f,sizeof(drec),ads drec);
           WRITELN('GETTING RECORD ',I:1,'. I=',drec.i:1);
          end;
         close(f);
 end.

 ---------------------------------------------------------------------------

 Response:
    In Version 3.3x, I/O to DIRECT files is buffered. This change was
 made to increase performance but, unfortunately, as a result of this
 change, it is no longer feasible to use the UNIT U functions GETUQQ()
 and PUTUQQ(). The only way to correct this is to take the buffering
 back out. This will not be done because we feel that the resulting
 degradation in performance would be more of a problem than the loss of
 use of these UNIT U routines.
    The loss of functionality to users resulting from this problem is
 minimal. GETUQQ()/PUTUQQ() is used to read/write strings of WHOLE
 records to a DIRECT file, starting at some record position, from/to a
 buffer. For this purpose, it is easy to build procedures using the
 intrinsics GET(), PUT(), and SEEK() to do the job. Furthermore, for
 small record lengths (small compared to the buffer size, 512) it is
 likely that such procedures would perform much better (i.e., faster)
 than using GETUQQ() and PUTUQQ() did in 3.20. The following MODULE
 illustrates one way you could implement procedures with equivalent
 functionality for most applications. (No claim is made that this is
 the best possible way.)

 -----------------------------------------------------------------------------
 {$INCLUDE: 'finkxu'}
 module io_recs [];
 uses filkqq;

 {* Procedure ERROR_CHECK checks for three possible error conditions in   *}
 {* in the parameters passed to GET_RECORDS() or PUT_RECORDS() and ABORTS *}
 {* the program if any of these are found. The parameter PROC_FLAG        *}
 {* identifies the procedure which called ERROR_CHECK, PROC_FLAG = 1 for  *}
 {* GET_RECORDS() and PROC_FLAG = 2 for PUT_RECORDS().                    *}

 PROCEDURE ERROR_CHECK(VAR F: fcbfqq; position: integer4; count: word;
 BUFF_ADS: adsmem; proc_flag: word);

 begin
    if f.cmod <> direct then
       abort('ERROR - FILE NOT OPENED FOR DIRECT ACCESS', 10000,
       proc_flag)
    else if count = 0 then
       abort('ERROR - I/O OF 0 RECORDS REQUESTED', 10001, proc_flag)
    else if (bylong(0, buff_ads.r) + bylong(0, count)*bylong(0, f.size))
    >= 65536 then
       abort('ERROR - BUFFER CANNOT SPAN SEGMENTS', 10002, proc_flag)
 end; { error_check }

 {* Procedure GET_RECORDS() copies COUNT records from file F, starting at *}
 {* record POSITION, to the buffer whose address is DESTINATION.          *}

 PROCEDURE GET_RECORDS (VAR F: fcbfqq; position: integer4; count: word;
 DESTINATION: adsmem) [public];

 VAR   I: word;
       CURR_DEST: adsmem;

 begin
    {error_check(f, position, count, destination, 1);}
    CURR_DEST := destination;
    seek(f, position);
    FOR I := 1 to count do begin
       get(f);
       movesl(ads (f^), curr_dest, f.size);
       CURR_DEST.R := curr_dest.r + f.size
    end { end of for }
 end; { get_records }

 {* Procedure PUT_RECORDS() copies COUNT records from the buffer whose    *}
 {* address is SOURCE to the file F, starting at record POSITION.         *}

 PROCEDURE PUT_RECORDS (VAR F: fcbfqq; position: integer4; count: word;
 SOURCE: adsmem) [public];

 VAR   I: word;
       CURR_SRC: adsmem;

 begin
    {error_check(f, position, count, source, 2);}
    CURR_SRC := source;
    seek(f, position);
    FOR I := 1 to count do begin
       movesl(curr_src, ads (f^), f.size);
       CURR_SRC.R := curr_src.r + f.size;
       put(f)
    end { end of for }
 end; { put_records }

 end.


 79. PAS2 Does Not Set the DOS ERRORLEVEL in Version 3.30

 Product Version(s): 3.3x
 Operating System:   MS-DOS
 Flags: ENDUSER | TAR51089 buglist3.30 fixlist3.31
 Last Modified: 24-FEB-1988    ArticleIdent: Q10940

 Question:
    According to the documentation (Pascal user's guide, Page 134),
 "The compiler supplies an exit status (to MS-DOS Versions 2.0 and
 later) that can be accessed via the IF ERRORLEVEL N batch command...".
    Unfortunately, in the case of PAS2.EXE running out of memory, it
 does not do this.

 Response:
    This problem was present in Version 3.30 of the compiler. There is
 a module called mis2 that contains error handling routines that
 interface with the Pascal run-time routines in the compiler. It was
 not properly setting the doseqq cell. This problem was corrected in
 Version 3.31.


 80. MIN Is an Undocumented Function

 Product Version(s): 3.3x
 Operating System:   MS-DOS
 Flags: ENDUSER | TAR51923
 Last Modified: 30-SEP-1988    ArticleIdent: Q10992

 Question:

 In a program we declare the global variable "MIN". When we link the
 program we get a "symbol defined twice" error message. Is there a
 procedure MIN that is used by the compiler?

 Response:

 It is not a reserved word, but it is an undocumented function defined
 in the library. The library function min() does just what you would
 expect; it returns the minimum of its two arguments. However, the
 argument type and return type are WORD rather than INTEGER. Thus, the
 following declaration should be made:

 FUNCTION MIN(I,J: word): integer; extern;

 There is no function MAX() defined in the library.


 81. $mathck and Integer2 Expressions

 Product Version(s): 3.3x
 Operating System:   MS-DOS
 Flags: ENDUSER | TAR21809
 Last Modified:  4-OCT-1988    ArticleIdent: Q11000

 Problem:

 Page 61 of the "Microsoft Pascal Reference Manual" describes how
 integer2 variables will be changed within a formula to integer4 if the
 result will be out of integer2's value range. However, if you use the
 metacommand $mathck as described on Page 323, this does not work
 correctly. The program will terminate with the error message "out of
 integer space."

 The following example code demonstrates this problem:

     { changing to INTEGER4 as described in Pascal reference manual }
     { on Page 61 is not done when mathck+ is set }

     { $mathck+ }
     {$line+}
     program p_f01(output);
     VAR L:integer4;
         I1:integer4;
         I: integer;
     begin
     writeln('no error message using only INTEGER4 variables');
     I1:= 1000;
     L:= I1*I1;
     writeln('1000*1000 = ',L);
     writeln;
     writeln('using INTEGER2 variables in expression, result assigned to ');
     writeln('a variable of typ INTEGER4');
     I:=1000;
     L:=I*I;     { will stop with error message right here }
     writeln('1000*1000 = ',l)
     end.

 Response:

 {$Mathck+} only tells you what the compiler finds. It evaluates the
 right-hand side as an integer2 expression, and finds that it cannot
 fit the result into an integer2 variable. More explicitly, it
 evaluates the right-hand side, determines that I is integer2,
 calculates the result, and then determines that the result is not
 integer2 and gives you an overflow error.

 The conversion of the result to an integer4, which happens if you
 delete the {$mathck+} metacommand, occurs at the assignment statement,
 not at the calculation of a result. But $mathck keeps a closer eye on
 the intermediate results, notes that the results do not fit into a
 variable of the type of those variables on the right-hand side, so it
 overflows and gives the error, never making it to the assignment that
 would have resolved the problem.

 To work around this problem, you can multiply the expression on the
 right-hand side by an integer4 1. The compiler will then evaluate the
 results of the right-hand side as an integer4 rather than integer2 and
 so $mathck+ will not give you an error.

 The following is an example:

     {$mathck+}
     {$line+}

     program test(output);
     VAR L4, I4, J4:integer4;
                  I:integer ;
     begin
          I4:= 1000;
          L4:= I4*I4;
          J4:= 1;
          writeln('1000*1000 = ',L4);
          I:=1000;
          L4:=J4*I*I;
          writeln('1000*1000 = ',L4)
     end.

 This code produces the following results:

 1000*1000 =        1000000
 1000*1000 =        1000000

 Note: you need to place the J4 at the beginning of the right-hand
 expression. The statement L4:=I*I*J4; results in the same error. That
 is because at the evaluation stage, it will evaluate it according to
 the type of the first (left-most) variable that it finds.


 82. Decimal Fractions Suffer Binary Round-off

 Product Version(s): 3.13 3.20 3.3x 4.00
 Operating System:   MS-DOS
 Flags: ENDUSER | TAR21448
 Last Modified: 29-SEP-1988    ArticleIdent: Q11001

 Problem:

 The following bankers rounding described in the "Microsoft Pascal
 User's Guide" on Page 165 does not work correctly:

 trunc(4.5)   result is 4         correct
 trunc(207.5) result is 207       should be 208

 This problem occurs with PASCAL.LIB and ALTMATH.LIB.

 Response:

 This is not a bug. Certain rational decimal numbers are not precisely
 representable in binary. As a result, the representation of a fraction
 may actually be slightly less than the fraction. Therefore, when the
 TRUNC function is performed, the result may be unexpected. When real
 numbers are decoded, the number is rounded to ensure correct results.

 The following example also illustrates this problem. When you use real
 numbers, performing a loop that adds 0.1 each time and then uses
 TRUNC, the results will be off eventually. In this example it becomes
 inaccurate after five increments of the loop. It becomes inaccurate
 because it truncates to 4.00 when it should have returned
 5.00.

 The following sample code demonstrates the problem:

     PROGRAM DEGTST(INPUT,OUTPUT);
     VAR PRTF:TEXT;
         I,J,DEG,TMP1:REAL;
     BEGIN
       ASSIGN(PRTF,'PRN');
       REWRITE(PRTF);
         TMP1:=4.5;
       REPEAT
         I:=TRUNC(TMP1);
         DEG:=TMP1 * 100.0;
         J:=TRUNC(DEG);
         WRITELN(PRTF,'I',I:3:2,' TMP1 ',TMP1,'DEG',DEG,' J',J:3:2);
         TMP1:= TMP1 + 0.1;
       UNTIL TMP1>6.0
     END.

 In your particular case, the following program illustrates the
 problem:

     PROGRAM TEST(OUTPUT);
     VAR I1 , I2: INTEGER;
     BEGIN
             I1:=TRUNC(4.5);
             I2:=TRUNC(207.5);
             WRITELN(I1);
             WRITELN(I2)
     END.

 If you check, the number 207.5 is indeed not precisely representable
 using binary arithmetic. It is in fact somewhat less than 207.5 in
 binary arithmetic. Thus, when you truncate it, the number returned will
 be 207.


 83. Clarification of Enumerated Type's Size

 Product Version(s): 3.3x
 Operating System:   MS-DOS
 Flags: ENDUSER | TAR21431
 Last Modified:  4-OCT-1988    ArticleIdent: Q11067

 Problem:

 There is an example in the "Microsoft Pascal Compiler Reference
 Manual" for the RETYPE procedure. If the example is followed exactly,
 the following warning message is given upon compiling:

 Warning 248 size not identical.

 Response:

 Because the enumerated type in question has only three values (COLOR =
 (RED, GREEN, BLUE)), values of this type are stored in one byte. This
 explains why the warning error occurs when the integer constant is
 RETYPEd as a COLOR. If the enumerated type COLOR had been defined to
 have more than 255 values, then values of type COLOR would be stored
 in a word (two bytes) and the warning error would not occur.


 84. VALUE Is a Reserved Word

 Product Version(s): 3.13 3.20 3.3x
 Operating System:   MS-DOS
 Flags: ENDUSER | TAR52108
 Last Modified: 30-SEP-1988    ArticleIdent: Q11077

 Question:

 What is wrong with the following Pascal program?

     program pem(input,output,em,errors);
     type
       idclass=  (types,konst,qvars,stcnst,field,carrbnd,proc,func);
       where=    (blck,rec,wrec);
       nameinfo=record
         CASE OCCUR:where of
           REC: (linker: integer);
         end;

         identifier=record
           CASE KLASS:idclass of
      KONST  : (value  :  integer);
         end;
     begin
     end.

 Response:

 The only change necessary is to rename your variable "value" because
 "value" is a reserved word (see Page 373 of the "Microsoft Pascal
 Version 3.32 Reference" manual, in Appendix E, "Summary of Microsoft
 Pascal Reserved Words").

 The error messages that you receive when you run PAS1 are confusing.
 Here is a summary of the process used in debugging your program:

 If you examine the line that causes the error for anomalies, the first
 thing to check is the syntax of a similar (successful) piece of code.

 There is an example in the manual of a very similar piece of code. On
 Page 79 of the Pascal Version 3.32 reference manual, in Section 7.3.1,
 "Variant Records", the example of the record "FOO" is very similar.
 After consulting this example, the only obvious difference is that
 there are no semicolons at the end of the line preceding the end
 statement. That should not create these errors, however, and indeed
 changing that does not do anything.

 Because the format of the line is correct, you have to look for
 something else. The variable "value" is a possible cause of error
 because it is a general name that might be used by the compiler for
 something else. Looking in the appendix concerning Pascal reserved
 words, you will find VALUE. Changing VALUE to a non-reserved word
 results in successful compilation.


 85. GTYUQQ, PTYUQQ Equivalent to BLOCKHEAD, BLOCKWRITE

 Product Version(s): 3.30 3.31 3.32
 Operating System:   MS-DOS
 Flags: ENDUSER | TAR52369 docerr
 Last Modified: 18-AUG-1988    ArticleIdent: Q11095

 Question:
    On Page 368 of the "Microsoft Pascal Compiler Reference Manual"
 ("Differences between MS-Pascal and UCSD Pascal") it makes reference
 to two functions, GETUQQ and PUTUQQ, as being equivalent to the UCSD
 functions BLOCKREAD and BLOCKWRITE. This is the only reference to
 these functions and there is no description of their use. Are these
 functions available? Is this a documentation problem?

 Response:
    This is a documentation error. The correct functions are GTYUQQ
 (Page 238 in the Pascal reference manual) and PTYUQQ (Page 249 of the
 same manual).


 86. PAGE(file) Incorrectly Sends Extra Line Feed in Version 3.31

 Product Version(s): 3.3x
 Operating System:   MS-DOS
 Flags: ENDUSER | TAR52568 buglist3.31 fixlist3.32
 Last Modified: 24-FEB-1988    ArticleIdent: Q11122

 Problem:
    If PAGE(file) is used with the file assigned to logical devices
 "prn" or "lpt1", the printer will correctly do a form feed to advance
 the page.
    However, an extra line feed also is being sent to the printer,
 resulting in the printer not being at the top of the form, but at the
 top of the form plus one line.
    The main problem is that if the printer is turned off after the
 program does a form feed, the next time the printer is turned on, the
 page will be off by one or more lines and the problem will compound
 each time the printer is turned off and on again.

 Response:
    This is a known problem in our Pascal Version 3.31 compiler. This
 problem was corrected in Version 3.32.


 87. XENIX Intermediate Code Incompatibility

 Product Version(s): 3.30
 Operating System:   XENIX
 Flags: enduser |
 Last Modified: 22-FEB-1988    ArticleIdent: Q11140

 Question:
    Do Microsoft's compilers use the same intermediate code format as
 that specified by AT&T? Under System V, AT&T has their own type of
 Cmerge project where compilers such as the portable C compiler and the
 portable FORTRAN compiler use the same code generator.

 Response:
    No, Microsoft's compilers do not use the same intermediate code
 format as that specified by AT&T.
    To create the same intermediate code from one compiler to another,
 a detailed knowledge of the compiler internals is necessary. This is
 possible only if you have written the compiler, or if you have the
 source code and access to someone who built it.
    In our case, we have intermediate code compatibility within our own
 products, but not relative to AT&T.
    Intermediate code compatibility is not possible because our XENIX
 compilers are similar to our DOS compilers, without the DOS trimmings
 and instead with some XENIX trimmings. This makes us incompatible with
 AT&T, because our DOS compilers were built for intermediate code
 compatibility between MS-DOS PASCAL and FORTRAN (PAS2 is the same for
 both compilers).


 88. Table of Limitations of Various Linker Versions

 Product Version(s): 3.30
 Operating System:   MS-DOS
 Flags: enduser |
 Last Modified: 22-FEB-1988    ArticleIdent: Q11171

 Question:
    Apparently, there was a 384K limitation on the Pascal Version 3.2
 Linker. Is this still valid on Version 3.31? Are there any other
 limitations that are no longer valid? This applies to all versions of
 DOS and of the Linker.

 Response:
    Please see the application note in the MS-DOS FORTRAN database that
 deals with this subject. This application note is a table that
 summarizes the Linker limitations for all versions of the Linker and
 several versions of FORTRAN, Pascal, MASM, and C.


 89. Using the Long and Short Heap Together

 Product Version(s): 3.20
 Operating System:   MS-DOS
 Flags: ENDUSER | TAR52789
 Last Modified: 23-FEB-1988    ArticleIdent: Q11218

 Question:
    Is there any reason why the long heap and the short heap cannot be
 used together? I cannot find any reference to this in our manuals. The
 Convergent Technology Pascal compiler which is our Pascal only differs
 in one place when referring to the heap. It says that you cannot mix
 the two because the short heap requires contiguous memory and using
 the long heap will fragment memory causing the machine to crash. Is
 this true? I thought the short heap was constrained to the default
 data segment and the long heap took you out into the rest of memory.

 Response:
    There is no reason why you can't use both the long and short heaps
 with Microsoft DOS Pascal. The compiler itself uses both of them.
    The Convergent Technology version of the compiler has a different
 heap management system, and that is why it gives that warning.


 90. Determining and Setting the Stack's Size

 Product Version(s): 3.3x
 Operating System:   MS-DOS
 Flags: ENDUSER | TAR52656
 Last Modified: 22-FEB-1988    ArticleIdent: Q11220

 Question:
    How do you determine the optimum stack size for a program, besides
 using a trial and error method?
    How can we set the stack size?

 Response:
    There is no direct and simple method to determine the needed stack
 size. To get an estimate, do the following:

    1. Figure out the sequence of calls to functions made by the
 program.
    2. From this, estimate the approximate size of your stack, using
 the $symtab metacommand.
    3. Add a fudge factor of 10 percent plus 250 bytes.

    You may set the size of your program's stack at link time using the
 /STACK switch. You may also use the /STACK option of the EXEMOD
 utility. Note that the linker's stack switch accepts a decimal value
 for the stack size, where the stack size stipulated using EXEMOD is in
 hexadecimal.


 91. Stack Sizes for 3.20 to 3.3x

 Product Version(s): 3.20 3.3x
 Operating System:   MS-DOS
 Flags: ENDUSER | TAR52656 docerr
 Last Modified: 18-AUG-1988    ArticleIdent: Q11221

 Question:
    We are using Pascal Version 3.20, and we are trying to upgrade to
 Pascal Version 3.30. ".EXE" files created using the Pascal Compiler
 Version 3.30 and linker (Version 3.02), crash when run, due to stack
 overflow. We are not using any compiler or linker switches, and we are
 using Pascal.lib and Math.lib.
    Why does the documentation give conflicting information about using
 the /STACK switch of the Linker to increase the stack size? Page 66 of
 the "Microsoft Pascal Compiler User's Guide" warns you not to use the
 /STACK linker switch, and Page 155 of Appendix A warns you only to use
 the /STACK linker switch with programs compiled with Pascal
 Compiler Version 3.30 or later. Which of these two warnings is correct?

 Response:
    Page 155 of Appendix A is correct: the linker stack switch should
 only be used with Pascal Version 3.30 or later. Earlier versions
 allocated unused stack space for the near heap, causing problems if
 the /Stack switch was used.


 92. DGROUP too Large in Pascal

 Product Version(s): 4.00
 Operating System:   MS-DOS
 Flags: ENDUSER | SR# S880909-3
 Last Modified: 26-SEP-1988    ArticleIdent: Q35482

 If your DGROUP is running out of space, dynamically allocate some of
 your variables using ALLMQQ(). Pascal does not allow you to push your
 stack out of DGROUP. There is no data threshold switch (/Gt in C) for
 Pascal, so you cannot automatically push the data out of DGROUP like
 you can in C.


 93. Direct file I/O Unreliable in DOS or XENIX Pascal 3.30

 Product Version(s):
 Operating System:   XENIX
 Flags: enduser |
 Last Modified: 24-FEB-1988    ArticleIdent: Q11263

 PRODUCT: Pascal/3.30
 Problem:
 If you open a DIRECT file, write to it, close it, open it again, SEEK to
 one of the records you had previously written to, and attempt to PUT a new
 value into that record, then this new value will not be placed there and
 the directory length of the file is incorrect.
 Response:
 This problem exists in both Xenix and DOS Pascal.

 A work-around for MS-DOS is available on request; user either links with
 FILF.OBJ or replaces PASCAL.LIB with PASNEW.LIB.

 Theoretically the fix under DOS 3.X is to open the file under any sharing
 mode other than sm_compat or sm_denyrw to prevent Pascal from buffering the
 file, however this may not be practical under MS-NET.

 The problem does not occur if you do not close the file, i.e. you can open
 a file, place values in the records and then seek to individual records and
 write to them a second time to replace the previous value as often as you
 wish until you first close the file.

 PROGRAMMING WORK-AROUND:  First SEEK to record 256 and GET it before
 SEEKing to the record you want to write to.

 This problem was corrected in DOS Pascal version 3.31.


 94. Creating .INI Files

 Product Version(s): 3.31
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 24-FEB-1988    ArticleIdent: Q11412

 Question:
    I am very impressed with the file initialization that Windows uses
 (i.e., the concept of the .INI file). I would like to incorporate this
 concept into my project (HTLV-III screening) application, so that it
 will be more consistent with the Microsoft setup. Will Microsoft
 consider releasing more technical information about the setup?

 Response:
    There is no detailed technical information available at this time.
 However, the basic ideas are straightforward: you set an environment
 variable that contains the directory name where the .INI file is
 located. Your program accesses this .INI file to find the
 user-specified parameters that customize the installation. The .INI
 file can contain information for more than one product. This is done
 by using keywords, contained in brackets, e.g. [KEYWORD], followed by
 the switches and information needed by that program.
    With respect to specific implementation, here are brief
 descriptions of some helpers that we have created for internal use to
 process .INI files (we cannot give you our tools, but it should be
 fairly simple to create your own):

    1. A routine that checks the environment variables (this routine
 can be coded in C; there is a GETENV function that can be used to
 determine the environment variables) and then searches for the .INI
 file at the appropriate location.
    2. A routine that opens the .INI file and searches for the KEYWORD.
    3. A routine to process the information contained after the
 keyword. One way to do this is to give the program a pointer to a
 matrix that contains the fields, possible field values (you need
 default values), and attributes of those values (e.g. the value must
 be a character string, or if that value is "20," a certain switch is
 set).


 95. Decode Will Not Accept Leading Blanks in Version 3.31

 Product Version(s): 3.3x
 Operating System:   MS-DOS
 Flags: ENDUSER | TAR53149 buglist3.31 fixlist3.32
 Last Modified: 30-SEP-1988    ArticleIdent: Q11496

 Question:

 After converting from Pascal Version 3.30 to Version 3.31, the library
 function decode behaves differently. In earlier versions, leading
 blanks were acceptable for decode to work. In Version 3.31, the
 leading blanks must be removed. The following is an example:

     var
        RESULT: lstring(7);
        TOT   : real;

 begin
   RESULT:= '   12.97';   ! Worked before 3.31
   RESULT:= '12.97';      ! Works with 3.31
   RESULT:= '12.97   ';   ! Also OK with 3.31
   eval(decode(result,tot));

 Will this restriction be corrected? Old applications are no longer
 compatible.

 Response:

 Microsoft has confirmed this to be a problem in Version 3.31. This
 problem was corrected in Version 3.32.


 96. Using VAR in a Parameter List

 Product Version(s): 3.x
 Operating System:   MS-DOS
 Flags: ENDUSER | TAR52916
 Last Modified: 24-MAR-1988    ArticleIdent: Q11494

 Problem:
    In the following code (an excerpt from a larger program) the
 parameter list contains a variable "Table". All other procedures in
 the program that use Table use the parameter "VAR TABLE:TableArray",
 but in this example, the PrintTable procedure declares it
 "TABLE:TableArray".
    The program hangs because of this error. If you replace the
 parameter with "VAR TABLE:TableArray" the program works correctly. We
 think that the compiler should issue an error message in this
 instance.

 Response:
    The behavior of the Microsoft Pascal compiler is correct. In the
 program you used, the procedure PrintTable contains a parameter list.
 One of the parameters passed to PrintTable is "TABLE: TableArray;" and
 your claim is that the program did not use the parameter "VAR
 TABLE:TableArray".
    In Pascal, you can pass parameters to procedures by reference
 (using VAR, or VARS between Modules or Units) or by value (by
 default). If you use "TABLE:TableArray", you pass the parameter by
 value, while "VAR TABLE:TableArray" passes it by reference. Both
 methods are valid. Sometimes you may want to pass an array to a
 procedure by value, and that is correct Pascal usage. In your program,
 using the array in such a way hangs your program. But since both
 instances (passing arrays by reference and passing them by value) are
 correct Pascal usage, this is not an error on the part of the compiler
 but rather a logic error that the user is responsible for. The
 following is a short code excerpt:

 {---------------------------------------------------------------------------}
 {Search table for word if found increment count else call InsertWord.       }
 {---------------------------------------------------------------------------}

 PROCEDURE SEARCHTABLE (VAR TABLE: TableArray;        {<--Used correctly}
                    VAR TABLESIZE: integer;
                             WORD: String ;
          VAR FIRST, LAST, MIDDLE: integer);

 var
      FOUND: boolean; {Check to see if word is found}

 begin {SearchTable}
 FIRST:= 1;
 LAST:= TableSize;
 FOUND:= false;
 while (Last >= First) and (not Found) do
      begin {while}
      MIDDLE:= (First + Last) div 2;
      if Word < Table [Middle].Word then
              LAST:= Middle - 1
      else
      if Word > Table [Middle].Word then
              FIRST:= Middle + 1
      else
              begin {else}
              TABLE [MIDDLE].COUNT:= Table [Middle].Count + 1;
              FOUND:= true;
              end; {else}
      end; {while}
 if (Last < First) and (not Found) then
      InsertWord (Table, TableSize, First, Word);
 end; {SearchTable}

 {---------------------------------------------------------------------------}
 {Print the contents of Table to the screen.                                 }
 {---------------------------------------------------------------------------}

 PROCEDURE PRINTTABLE (TABLE: TableArray;             {<-- Correct usage but }
                    WordCount,                         {   incorrect logic  }
                   SENTCOUNT: integer);

 var
      TABLET: integer; {Loop control variable in for loop}

 begin {PrintTable}
 writeln;
 WRITELN ('CONTENTS OF: ',FileName);
 WRITELN ('TOTAL SENTENCES: ',SentCount:1);
 WRITELN ('TOTAL UNIQ WORDS: ',TableSize:1);
 WRITELN ('TOTAL WORDS: ',WordCount:1);
 writeln;
 FOR TABLET:= 1 to TableSize do
      WRITELN (TABLE [TABLET].WORD,TABLE [TABLET].COUNT:1);
 end; {PrintTable}


 97. Adding FORTRAN Library Routines to Pascal

 Product Version(s): 3.3x
 Operating System:   MS-DOS
 Flags: ENDUSER | TAR53709
 Last Modified: 23-FEB-1988    ArticleIdent: Q11503

 Question:
    Can developers put FORTRAN Version 3.3x library routines into the
 Pascal Version 3.3x library?

 Response:
    Yes, it is possible to break up the FORTRAN Version 3.3x libraries
 into object modules that can be used by Pascal (using the LIB
 utility). This is tricky at best, and we do not support it.
    We do not guarantee forward compatibility if you do this.


 98. Problems with the Ads of an Array

 Product Version(s): 3.31
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist3.31 fixlist4.00
 Last Modified:  4-OCT-1988    ArticleIdent: Q11585

 Under the following conditions, incrementing the index by one fails:

 1. A field of a record is an ads of an array.
 2. Another field is the index to the array.
 3. The array is allocated on the long heap.
 4. The record is passed by VARS and the array is referenced.

 The program adstest2.PAS (below) demonstrates this behavior. The
 record variable BUFFER is passed to Procedure Increment by VARS. The
 statement labeled "instruction 1" references the elements of the
 array. "Instruction 2" increments the array's index (BUFFER.CUR).
 However, BUFFER.CUR is not being incremented, as can be seen by
 running the program. "Instruction 3" prints the unincremented index.
 Microsoft is researching this problem and will post new information as
 it becomes available.

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

 The following notes apply:

 1. Delete the statement labeled "Instruction 1" and the program
    works successfully (see adstest3.PAS).

 2. Use BUFFER as a global variable rather than passing it to
    Procedure Increment by VARS, and the program works successfully
    (see adstest1.PAS).

 3. adstest2.PAS works successfully under Pascal Version 3.20.

 The following are short example codes:

 Short Example Code: adstest1.pas

     program test(input,output);
     type    ads_table=ads of array[1..32766] of char;
             buffer_typ=record
                             TABLE_ADS:ads_table;
                             CUR:integer;
                             FINISH:integer;
                        end;

     const   size=200;

     VAR     BUFFER:buffer_typ;
             CH:char;

     FUNCTION ALLMQQ(WANTS:word):adsmem;extern;

     procedure initialize_buffer;
     begin
             BUFFER.TABLE_ADS:=allmqq(size);
             BUFFER.FINISH:=size;
             BUFFER.CUR:=1;
     end;

     procedure increment;
     begin
       repeat
             CH:=buffer.table_ads^[buffer.cur];     {instruction 1}
             BUFFER.CUR:=buffer.cur + 1;            {instruction 2}
             WRITELN('BUFFER.CUR = ',BUFFER.CUR:1); {instruction 3}
       until (buffer.cur > buffer.finish);
     end;

     begin {main}
             initialize_buffer;
             increment;
     end.

 Short Example Code:  adstest2.pas

     program test(input,output);
     type    ads_table=ads of array[1..32766] of char;
             buffer_typ=record
                             TABLE_ADS:ads_table;
                             CUR:integer;
                             FINISH:integer;
                        end;

     const   size=200;

     VAR     BUFFER:buffer_typ;
             CH:char;

     FUNCTION ALLMQQ(WANTS:word):adsmem;extern;

     procedure initialize_buffer;
     begin
             BUFFER.TABLE_ADS:=allmqq(size);
             BUFFER.FINISH:=size;
             BUFFER.CUR:=1;
     end;

     PROCEDURE INCREMENT(VARS BUFFER:buffer_typ);
     begin
       repeat
             CH:=buffer.table_ads^[buffer.cur];     {instruction 1}
             BUFFER.CUR:=buffer.cur + 1;            {instruction 2}
             WRITELN('BUFFER.CUR = ',BUFFER.CUR:1); {instruction 3}
       until (buffer.cur > buffer.finish);
     end;

     begin {main}
             initialize_buffer;
             increment(buffer);
     end.

 Short Example Code: adstest3.pas

     program test(input,output);
     type    ads_table=ads of array[1..32766] of char;
             buffer_typ=record
                             TABLE_ADS:ads_table;
                             CUR:integer;
                             FINISH:integer;
                        end;

     const   size=200;

     VAR     BUFFER:buffer_typ;
             CH:char;

     FUNCTION ALLMQQ(WANTS:word):adsmem;extern;

     procedure initialize_buffer;
     begin
             BUFFER.TABLE_ADS:=allmqq(size);
             BUFFER.FINISH:=size;
             BUFFER.CUR:=1;
     end;

     PROCEDURE INCREMENT(VARS BUFFER:buffer_typ);
     begin
       repeat
             BUFFER.CUR:=buffer.cur + 1;            {instruction 2}
             WRITELN('BUFFER.CUR = ',BUFFER.CUR:1); {instruction 3}
       until (buffer.cur > buffer.finish);
     end;

     begin {main}
             initialize_buffer;
             increment(buffer);
     end.


 99. PASIBF.OID and PASIBF.TMP in XENIX Pascal

 Product Version(s): 3.30 3.31
 Operating System:   XENIX
 Flags: ENDUSER |
 Last Modified:  4-OCT-1988    ArticleIdent: Q11592

 Problem:

 When I use the cl driver with the -c option as follows, the files
 PASIBF.OID and PASIBF.TMP are left in the current working directory:

 cl -c dummy.c

 These are the intermediate files from PAS2 to PAS3 so that an object
 file listing can be made.

 Although I have not asked for an object files listing, cl still
 creates them.

 Response:

 Microsoft has confirmed this to be a problem in Versions 3.30 and 3.31.

 To work around this problem, delete your temporary files.


 100. Run-Time Library Compatibility with FORTRAN

 Product Version(s): 3.13 3.20 3.3x
 Operating System:   MS-DOS
 Flags: ENDUSER | TAR53708
 Last Modified: 23-FEB-1988    ArticleIdent: Q11501

 Question:
    Are the REAL functions from the Microsoft FORTRAN Run-Time Library
 compatible with the Pascal DECMATH.LIB Library? How about the other
 Pascal libraries?

 Response:
    No, the Pascal DECMATH Library is not compatible with the FORTRAN
 Run-Time Library. However, the regular Pascal Version 3.3x Run-Time
 Library is compatible with the FORTRAN 3.3x Run-Time Library.


 101. Limit on Nesting Units or Include Files

 Product Version(s): 3.3x
 Operating System:   MS-DOS
 Flags: ENDUSER | TAR53861 docerr
 Last Modified: 23-FEB-1988    ArticleIdent: Q11582

 Problem:
    The manual does not say that there is a limit on the number of
 units or $include files one can nest in Pascal.
    If you nest units six levels deep, the compiler will give a warning
 118: too many file levels, followed by error 366: unit identifier
 expected skip to. From the sample program, if you nest up to five
 levels the compiler will not give the warning message. It seems that
 there is a limit on how many levels one can do.

 Response:
    There is an undocumented limit of five levels of nesting for units
 and include files. This documentation omission will be corrected in a
 future release.


 102. Extra Line Feeds with WRITE in Version 3.31

 Product Version(s): 3.31 3.32
 Operating System:   MS-DOS
 Flags: ENDUSER | TAR54481 buglist3.31 fixlist3.32
 Last Modified: 30-SEP-1988    ArticleIdent: Q11679

 Problem:

 Pascal Version 3.31 I/O seems to be behaving incorrectly. Line feeds
 are inserted when they should not be. If I use the following
 statements a carriage return is executed, but not a line feed:

     WRITE('ENTER A NUMBER');
     READLN;
     READ(F);

 As a result, the output is (and should be) overwriting the previous
 output. If the above statements are executed a second time, however, a
 line feed is inserted in the first write statement.

 Below is a copy of a program that duplicates the problem. This program
 works correctly in Version 3.20. However, in Version 3.31, if you
 execute the following program more than once you will see the line
 feed being inserted incorrectly with the first write statement:

     program test2(input,output);
     var
      num:integer;
      rnum:real;
      letter:char;

     begin
       write('enter a number (integer):');
       read(num);
       write('enter a real number: ');
       readln;
       read(rnum);
       write('enter a char:');
       readln;
       read(letter);
       writeln('The number is: ',num:3);
       writeln('the letter is: ',letter);
       writeln('the real number is:',rnum:5:2);
     end.

 Response:

 Microsoft has confirmed this to be a problem in Version 3.31. This
 problem was corrected in Version 3.32.


 103. Pascal Library Function Hdluqq Obtains Integer File Handles

 Product Version(s): 3.1x 3.20 3.3x 4.00 | 4.00
 Operating System:   MS-DOS              | OS/2
 Flags: ENDUSER | docerr
 Last Modified: 18-AUG-1988    ArticleIdent: Q32085

    To determine the integer file handle for a file opened in Pascal,
 you can use the Pascal library function Hdluqq as the following
 program demonstrates.
    On Page 386, under "Functions" in the index of the "Microsoft
 Pascal Compiler Reference" manual (Version 4.00), "HDLUQQ" is listed,
 but there is no documentation on this function in this manual.
 However, the "HDLUQQ" function is actually documented in the
 "Microsoft Pascal Compiler User's Guide" (Versions 3.20 to 4.00) on
 Page 133, Section 10.5.1.

    The following program uses the Pascal library function HDLUQQ to
 obtain the integer files handle of the files opened by the Rewrite or
 Reset functions. This program will work in both DOS and OS/2, although
 the respective operating systems do not open the file handle numbers
 in the same manner.
    Pascal only uses File Control Block stream files, and has no direct
 file I/O functions, so accessing the file handle is of little value in
 Pascal; however, the file handle could be passed to a Microsoft C or
 Macro Assembler routine.

 }

 program GetFileHandleWith_HDLUQQ(input,output);
     var
         f1, f2     : text; {File variables; for sequential text files here.}
         filehandle : integer;

     {Predeclare the Pascal library function Hdluqq. Hdluqq returns
      a 2-byte integer file handle for the stream file variable
      passed by reference to Hdluqq as an argument. Note that stream
      files use File Control Blocks, hence the name of the parameter
      below.
     }
     function Hdluqq (var FCBvariable : text) : integer; extern;

 begin
     {In DOS, the first available file handle should be 5. In OS/2, it
     ordinarily is file handle 3. Close the file to make the file
     handle available again.
     }
     assign(f1,'file1');
     rewrite(f1);
     filehandle := Hdluqq(f1);
     writeln;
     writeln('File handle for first  user-opened file = ',filehandle:3);
     writeln('Close this file and make its file handle available for reuse.');
     writeln;
     close(f1);

     {Open a second file. Note that file is not closed until the program's
     end.
     {
     assign(f2,'file2');
     rewrite(f2);
     filehandle := Hdluqq(f2);
     writeln('File handle for second user-opened file = ',filehandle:3);
     writeln;

     {Get the file handle for an existing file opened by reset.}
     reset(f1);
     filehandle := Hdluqq(f1);
     writeln('File handle for reopened first file     = ',filehandle:3);
     writeln;
     writeln('Good-bye.');
     close(f1);

     close(f2)
 end.


 104. Math Errors on 80286 and 80386 with Pascal Versions 3.13, 3.20

 Product Version(s): 3.13 3.20
 Operating System:   MS-DOS
 Flags: ENDUSER | appnote
 Last Modified:  4-NOV-1988    ArticleIdent: Q32093

 If you perform floating-point math calculations on 80286 or 80386
 machines with Pascal Versions 3.13 or 3.20 emulators or 87 math
 libraries, the computer hangs or returns incorrect answers.

 The same program that generates correct floating-point results on 8088
 or 8086 machines, such as the IBM PC/XT, will not work correctly on
 80286s, such as the IBM PC/AT (IBM AT), or 80386s, such as the Compaq
 Deskpro 386 or the IBM PS/2 Model 80.

 This problem occurs because the libraries provided with the Pascal
 compiler Versions 3.13 and 3.20 do not recognize the absence of an
 80287 or 80387 math coprocessor when run on 80286 or 80386 processors;
 these chips were created after Pascal Versions 3.13 and 3.20.

 For Pascal Version 3.20, but not for Pascal Version 3.13, this problem
 can be avoided by adding the following SET command to your
 environment, either by entering it at the operating system prompt or
 by first running a batch file that contains the SET command as
 follows:

    SET NO87=8087 SUPPRESSED

 For Pascal Versions 3.13 and 3.20, the problem can be corrected with
 an application note available from Microsoft Product Support Services
 by calling [phone].


 105. File Access Error In <file>.PAS; Code 1140; Status 110

 Product Version(s): 4.00   |4.00
 Operating System:   MS-DOS |OS/2
 Flags: ENDUSER | MS-DOS OS/2 docerr
 Last Modified:  2-DEC-1988    ArticleIdent: Q32251

    When PAS1 or PL of the Pascal Version 4.00 compiler cannot locate a
 file it is looking for, it issues the following undocumented error
 message:

    File Access Error In <filename>.PAS; Code 1140; Status 110
    Compiler Cannot Continue

    PAS3 can issue a similar message, as follows:

    File access error in file pasibf.sgt, error code 1140

    While not documented, these error message indicate the cause of the
 problem: a file name was referenced, but the compiler cannot find the
 file. With the earlier Pascal Version 3.32, the equivalent PAS1 error
 message was as follows:

    File access error in file <name>.PAS; Code : 1032; Status : 2

    With Pascal Version 3.32, the equivalent PAS3 error message was as
 follows:

    File access error in file PASIBF.OID, error code 1032

    The following three types of files being searched for by the
 compiler may result in the error:

    1. The source (.PAS) file could not be found by PAS1 or PL, either
       in the current working directory (by default), or by the path
       specified. A user typographical error, an incorrectly specified
       path, or nonexistent file is the typical cause of this error.
       Under DOS, it could be due to running out of file handles which
       could be corrected by adding the line "FILES=20" to the
       CONFIG.SYS file, and rebooting the computer. Interference from
       terminate but stay resident in memory software (TSR) could also
       be a problem under DOS.
    2. An include file indicated by the $include metacommand could not
       be found, either in the current working directory, with the
       specified path, or in the directory(s) specified by the compiler
       option /I<include_file_directory> or the SET INCLUDE=
       environment variable. Under DOS, it could also be due to running
       out of file handles as mentioned above.
    3. A compiler created symbol file was expected, but not found.
       There are two primary reasons for this:
       a. You ran PAS3 without first explicitly specifying that you
          wanted a .COD file in PAS1. PAS3 is looking for the compiler
          intermediate symbol files PASIBF.OID or PASIBF.SGT.
       b. Using the /Zi or /Zd compiler switch for CodeView debugging
          information with PAS1;, /Zi is a PL option and not a PAS1
          option. (Use the /Z option for CodeView information with
          PAS1.) If /Zi is incorrectly used with PAS1, the resulting
          error message is as follows:

          File Access Error In File i.PAS; Code : 1140; Status : 2


 106. Compiler Switches Used with PL Versus PAS1

 Product Version(s): 4.00
 Operating System:   MS-DOS
 Flags: ENDUSER | MS-DOS OS/2 docerr
 Last Modified: 30-SEP-1988    ArticleIdent: Q32252

 The PL compiler-linker driver uses different compiler switches or
 options than those used when invoking PAS1 of the compiler separately.

 The PL driver uses a modified form of the PAS1 compiler switches or
 options. A PAS1 option consists of a forward slash (/) followed by a
 single capital letter and the source filename, such as "PAS1 /D
 myfile.pas". The PL form of the same option is generally "PL /Pd
 myfile.pas". Note that the PL form of the PAS1 switch is "/P",
 followed by the PAS1 option letter in lowercase.

 Several exceptions to this general rule are documented on Pages
 Update-18 and Update-19 in the "Microsoft Pascal 4.0 Update." Also see
 Pages Update-20 to Update-27 for additional PL options not available
 with PAS1.


 107. Pascal 4.00 README.DOC: Filenames under OS/2

 Product Version(s): 4.00   | 4.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified: 26-SEP-1988    ArticleIdent: Q33268

 The following information was taken from the Pascal Version 4.00
 README.DOC file.

 File Names under OS/2

 Although DOS ignores any characters beyond the first eight in file and
 path names, OS/2 does not and instead reports an error. If you are
 using old batch or make files for OS/2 development, you may need to
 modify the files so that only eight characters and an extension are
 used in file and path names.


 108. PL Driver Uses /Zi Switch; PAS1 Uses /Z

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

 Problem:
    I am trying to compile a Pascal source-code file with the option to
 allow me to debug my program with CodeView. However, when I issue the
 following command:

    PAS1 /Zi myfile.pas;

 I get the following compiler error message for the file "i.PAS", even
 though I am not using "i.PAS":

    File Access Error In i.PAS; Code 1140; Status 110
    Compiler Cannot Continue

 Response:
    The "/Zi" compiler option is intended to be used only with the PL
 compiler-linker driver. When using PAS1, the equivalent switch is
 "/Z". The correct syntax would be one of the following:

          PAS1 /Z  myfile;

          PL   /Zi myfile.pas

    These options are documented in Table 2.1 on Page Update-19 of the
 "Microsoft Pascal 4.0 Update." Please note that the CodeView option
 under PL is incorrectly documented in the table as "/Z:" (/Z with a
 colon). The correct PL option for including CodeView information is
 "/Zi" (/Z followed by the lowercase letter "i").


 109. Building LIBPASE.LIB Using the Library Manager

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

 To build the combined emulator math Pascal library LIBPASE.LIB for DOS
 (which may be named LIBPASER.LIB if using both DOS and OS/2 without
 specifying the DOS mode library for the default), the component
 libraries below must be combined using LIB Version 3.11, the Library
 Manager.

 The component libraries listed below should be placed in the current
 working directory. The PATH environment variable should be set so
 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 LIBPASE.LIB

 Library does not exist.  Create? (y/n) y

 OPERATIONS: +PARTIAL.LIB +ENTX6L.OBJ +DOS30P.LIB&
             +IEEEMATH.LIB +EMR.LIB

 LIST FILE:  <Enter>

 OUTPUT LIBRARY:  <Enter>

 At this point, the Library Manager combines the component libraries
 into the combined library LIBPASE.LIB for DOS.

 For the combined emulator math library for OS/2 (named LIBPASEP.LIB if
 the default library naming convention was not requested for OS/2), the
 commands to LIB are as follows:

 LIB LIBPASEP.LIB

 Library does not exist.  Create? (y/n) y

 OPERATIONS: +PARTIAL.LIB +5ENTX6L.OBJ +DOS50P.LIB&
             +DOSCALLS.LIB+IEEEMATH.LIB +EM.LIB

 LIST FILE:  <Enter>

 OUTPUT LIBRARY:  <Enter>


 110. Defining Constants with /D and $IFDECL Metacommand

 Product Version(s): 4.00   | 4.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | MS-DOS OS/2 docerr
 Last Modified: 29-SEP-1988    ArticleIdent: Q32454

 Pascal Version 4.00 now provides the /D compiler command-line option
 for defining constants (but not variables) with values of integer,
 real, or single quotation-mark delimited strings of up to 76
 characters.

 This information is documented in the "Microsoft Pascal 4.0 Update" on
 Pages Update-21 and Update-22.

 There is also the new {$ifdecl <constant> $then} and associated
 {$else} and {$end} metacommands that provide conditional compilation
 of source code based on whether the <constant> has been previously
 defined at the command line with the /D option. The documentation for
 these metacommands is on Pages Update-35 and Update-36. (Constants
 defined in the CONST section of the source file are not used for the
 conditional compilation metacommands.)

 With the /D compiler option, no value needs to be explicitly assigned
 to the constant to use with {$if <constant> $then}. The default
 constant value will be the integer 1. Do not include spaces in a
 /D<constant> or /D<constant>=<value> option string.

 Remember the dollar sign before "$then" in the {$if <constant> $then}
 metacommand. Leaving the "$" off of "$then" results in Warning 122
 Invalid Metacommand Skipped.

 Note that the value assigned to the constant with /D can be redefined
 later, such as when compiling an assignment to the same constant in
 the CONST section of the source file. The /D option defines constants
 first, then assignments may be made in the CONST section of source
 code. The last definition of a constant will be the one used for later
 calculations and output.


 111. Using Exponentiation Functions Prsrqq and Prdrqq

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

 The functions prsrqq and prdrqq perform exponentiation on single- or
 double-precision floating-point numbers respectively.

 The definitions of these functions are incorrectly documented on
 Page 249 of the "Microsoft Pascal 4.0 Compiler Reference Manual." The
 parameters for both functions must be defined as VARS, not as value
 parameters as documented.

 The program below demonstrates the use of the Pascal library functions
 that perform exponentiation for floating-point bases and exponents.

 Function prsrqq performs exponentiation on real4 values; function
 prdrqq performs exponentiation on real8 values. The purpose of each
 function is to raise the first argument "a" to the "b" power, or a**b.

 Note that both prsrqq and prdrqq must be declared extern, and the
 parameters must be declared with VARS. The documentation on Page 249
 of the "Microsoft Pascal 4.0 Compiler Reference Manual" is incorrect
 in defining the parameters as being passed by value. Defining the
 parameters as passed by value will result in function return values of
 0.0, 1.0, or #INF (Infinite).

 Defining the parameters passed to prsrqq by VAR (not VARS) also
 results in 0.0. Defining the parameters passed to prdrqq by VAR
 results in the run-time error "Error: negative REAL to REAL Power"
 "Error Code 2133"

 The following program demonstrates the use of the prsrqq and prdrqq
 functions:

 program Exponentiation_Functions(input,output);
 var a4,b4,r4 : real4;  {operands, return value for prsrqq function call}
     a8,b8,r8 : real8;  {operands, return value for prdrqq function call}

 function prsrqq (vars a,b: real4): real4; extern; {Single precision a**b}
 function prdrqq (vars a,b: real8): real8; extern; {Double precision a**b}

 begin {main}
     a4 := 2.5;
     b4 := 3.0;
     r4 := prsrqq(a4,b4);

     a8 := 3.1415927;
     b8 := 2.0;
     r8 := prdrqq(a8,b8);

     writeln;
     writeln('Single precision prsrqq of 2.5       ** 3.0 = ',r4);
     writeln('Double precision prdrqq of 3.1415927 ** 2.0 = ',r8)
 end.  {main}


 112. Substitutes for Unimplemented SHL, SHR Operators

 Product Version(s): 4.00   | 4.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified: 26-SEP-1988    ArticleIdent: Q32456

 The unsigned left- and right-shift operators Shift Left (SHL) and
 Shift Right (SHR) have never been implemented in Microsoft Pascal.
 They are referred to in several areas of the "Microsoft Pascal 4.0
 Compiler User's Guide" and the "Microsoft Pascal 4.0 Compiler
 Reference" manual, including Appendix B.3 "Unimplemented Features" on
 Page 166 of the "Microsoft Pascal 4.0 Compiler User's Guide."

 The program below demonstrates user-defined procedures that can be
 used instead of SHL and SHR. Note that the names SHL and SHR are
 reserved by the compiler, so the procedures used to replace them
 cannot use the names SHL or SHR.

 The program below demonstrates simple substitutes for the
 unimplemented unsigned SHL and SHR operators.

 No range checking of initial values or the results of calculations is
 performed.

 The value being shifted is a 16-bit word. Digits shifted beyond the
 range of the word are dropped. Zero fill is used.

 While not implemented, SHL and SHR are compiler reserved words so the
 substitute procedures have the names "mySHL" and "mySHR".

 The following is a sample program:

 program SHL_SHR_Substitutes(input,output);
 var w   : word;     {word to shift left or right     }
     n,i : integer;  {shift positions: + left, - right}

 {Using integer2 math, raise 2 to the Nth power. Return word.}
 function Int_2toNth(n : integer) : word;
     var i   : integer;
         sum : word;
     begin
         sum := 1;
         for i := 1 to n do
             sum := wrd(sum + sum);
         Int_2toNth := sum
     end;

 {Shift word logical left (unsigned) the equivalent of n binary digits.}
 procedure mySHL(var w : word; n : integer);
     begin
         w := wrd(w * Int_2toNth(n))
     end;

 {Shift word logical right (unsigned) the equivalent of n binary digits.}
 procedure mySHR(var w : word; n : integer);
     begin
         w := wrd(w DIV Int_2toNth(abs(n)))
     end;

 begin         {begin main}
     writeln;
     writeln;
     writeln('Demonstration of substitutes for SHL and SHR.');
     writeln;
     write('Enter word to operate on              : ');
     readln(w);
     writeln;
     write('Enter digits to shift ("-" for right) : ');
     readln(n);
     writeln;
     if n < 0 then
         mySHR(w,n)
     else
         mySHL(w,n);
     writeln('Result = ',w:5)
 end.          {end main}


 113. Incorrect Pascal Compiler Option for CodeView in README.DOC

 Product Version(s): 4.00
 Operating System:   MS-DOS
 Flags: ENDUSER | docerr
 Last Modified: 18-AUG-1988    ArticleIdent: Q32722

    The README.DOC file on the Microsoft Pascal Version 4.00 Compiler
 distribution disk labeled "Setup and Compiler" has the following
 errors:
    In the section titled "Microsoft Codeview Debugger," in the
 subsection "Microsoft Pascal Programs," the sentence for correcting
 the compiler options is itself incorrect. The option for including
 CodeView symbolic information when compiling with PAS1 is "/Z", not
 "/Zz" as stated in the README text, and not "/Zi" as printed in the
 Microsoft CodeView and Utilities manual. Both /Zi and /Zz are options
 for the PL compiler-linker driver only.


 114. Linker Error L4051: "Cannot Find Library"

 Product Version(s): 4.00   | 4.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified: 18-AUG-1988    ArticleIdent: Q32792

    When linking modules compiled under older versions of the Pascal
 compiler, it is common to receive the linker error message L4051:
 "Library not found." This is because the multiple libraries used with
 Versions 3.32 and prior have been combined into single library for
 Version 4.00.
    The old component library names are embedded into the .OBJ files of
 modules compiled with Pascal Versions 3.32 and prior. To avoid the
 linker error, use the /NOD option (or /NODEFAULTLIBRARYSEARCH) at link
 time and specify the libraries to be used as in the following:

 link /NOD my.obj, my.exe, my.map, libpaser.lib;



 115. PACKING.LST for Pascal Compiler Version 4.00

 Product Version(s): 4.00   | 4.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified: 20-OCT-1988    ArticleIdent: Q33216

 The following article was taken from the PACKING.LST file for Pascal
 Version 4.00.

 PACKING.LST for Microsoft(R) Pascal Compiler Version 4.0 (C) Copyright
 1987, 1988 Microsoft Corporation

 Documentation

 There are six manuals:

 Microsoft Pascal Compiler Version 4.0 Update
 Microsoft Pascal Compiler User's Guide
 Microsoft Pascal Compiler Reference
 Microsoft Mixed-Language Programming Guide
 Microsoft CodeView(R) and Utilities manual
 Microsoft Editor User's Guide

 The package also includes a quick reference guide and templates:

 Microsoft Pascal Compiler Quick Reference Guide
 Two function-key templates for the Microsoft CodeView debugger

 Disks

 The Microsoft Pascal compiler is distributed on nine 5- 1/4" disks or
 four 3-1/2" disks. The 3-1/2" disks are not included in this package.
 To obtain 3-1/2" disks, telephone Microsoft Consumer Response at
 1-800-426-9400 (in Washington and Alaska, call 206-882-8088). 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 of 9: Setup and Compiler

 README        DOC    Information made available after manuals
                      were printed
 PACKING       LST    Packing-list file (this file)
 SETUP         EXE    Pascal SETUP program
 87            EXE    80x87 Coprocessor presence detector
 BIND          EXE    Operating System/2 BIND
 ECH           EXE    Character echoing utility used by Microsoft
                      Editor
 EXP           EXE    Expunge utility (used with RM)
 ERROUT        EXE    STDERR Redirection Utility
 EXEHDR        EXE    EXE Header Utility
 EXEMOD        EXE    EXE File Header Utility
 EXEPACK       EXE    EXE File Compression Utility
 IMPLIB        EXE    Import Library Manager
 SETENV        EXE    Environment Expansion Utility

 (13 files)

 Disk 2 of 9: Utilities

 PAS1  EXE    Pascal compiler, Pass 1
 PAS2  EXE    Pascal compiler, Pass 2
 PAS3  EXE    Pascal compiler, Pass 3
 MAKE  EXE    Program Maintenance Utility

 (4 files)

 Disk 3 of 9: Examples

 LINK  EXE    Segmented-Executable Linker
 PL    EXE    Pascal/Link driver
 RM    EXE    File removing utility
 FINK         Unit F/U file definitions
 FINKXU       Unit F/U file definitions
 FINU         Unit F/U file definitions
 CLOCK INT    Time/date definitions
 INTRP INT    Interrupt definitions
 PASEXEC  INC Demo include file for demoexec.pas
 PORT  INT    INPORT OUTPORT definitions
 BSE   INT    OS/2 API definitions
 BSEDOS INT   OS/2 API definitions
 BSEERR INT   OS/2 API definitions
 BSESUB INT   OS/2 API definitions
 OS2   INT    OS/2 API definitions
 OS2DEF INT   OS/2 API definitions
 DEMOEXEC PAS Pascal demo program
 PRIMES   PAS Pascal demo program
 SORTDEMO PAS Pascal sort demo program
 MAKESORT BAT Pascal sort demo program makefile (DOS)
 MAKESORT CMD Pascal sort demo program makefile (OS/2)
 EMOEM ASM    MASM source to modify 87.LIB for
              non-IBM(R) compatibles
 ENTX6L ASM   Pascal startup source
 ENTXSTUB ASM Pascal startup source stub for OS/2

 (24 Files)

 Disk 4 of 9: Library 1

 UNDEL         EXE    File undeletion utility (used with RM)
 LVARSTCK OBJ  Variable heap support
 APILMR        OBJ    Binder helper
 ENTX6L        OBJ    MS-DOS  Pascal startup
 5ENTX6L  OBJ  MS OS/2 Pascal startup
 ENTX6W   OBJ  MS-DOS  Pascal startup Windows
 5ENTX6W  OBJ  MS OS/2 Pascal startup Windows
 API   LIB     OS/2 API interface
 DOS30P LIB    DOS helper library used during library build
 DOS50P LIB    OS/2 helper library used during library build
 EMR   LIB     Emulator library (DOS)
 EM    LIB     Emulator library (OS/2)
 87R   LIB     8087/80287 math library (DOS)
 87    LIB     8087/80287 math library (OS/2)
 CEXEC LIB     SPAWN/EXEC support for DOS only
 DOSCALLS LIB  API definitions
 PASLIBW  LIB  Windows startup for Pascal (Only for 2.03 SDK)
 WIN87EM  LIB  Windows Emulator math      (Only for 2.03 SDK)
 MAKELIB  BAT  Alternate Library build batch file (DOS)

 (19 Files)

 Disk 5 of 9: Library 2

 LIB   EXE    Library manager
 EXEC  EXE    Utility used only by ILINK
 ILINK EXE    Incremental linker
 NULF  OBJ    Runtime file i/o stub
 NULE6 OBJ    Math stub
 PARTIAL  LIB Helper library used during library build
 ALTMATH  LIB Large-model alternate-math library
 DECMATH  LIB Large-model decimal math library
 IEEEMATH LIB IEEE math library
 8087  LIB    8087/80287 math library (model independent)
 MAKELIB  BAT Alternate Library build batch file (DOS)
 MAKELIB2 BAT Alternate Library build batch file (DOS) part 2.

 (12 Files)

 Disk 6 of 9: Microsoft CodeView(R) for MS-DOS

 CV    EXE    Microsoft CodeView debugger
 CV    HLP    Help file for the Microsoft CodeView debugger
 CVPACK EXE   Debugging information packing utility
 MOUSE  COM   Mouse driver

 (4 Files)

 Disk 7 of 9: Microsoft CodeView(R) for MS OS/2

 CVP   EXE    Microsoft OS/2 CodeView debugger
 CVP   HLP    Help file for the Microsoft CodeView debugger

 (2 Files)

 Disk 8 of 9: Microsoft Editor

 CALLTREE EXE Produces book-mark files for C and ASM programs
 M     EXE    Microsoft Editor (MS-DOS)
 MEP   EXE    Microsoft Editor (MS OS/2)
 MEGREP EXE   Pattern finding utility (GREP)
 BRIEF INI    Brief editor key definitions
 EPSILON  INI Epsilon editor key definitions
 QUICK INI    Quick product editor key definitions
 WS    DLL    WordStar key emulation
 WS    ZXT    WordStar key emulation
 EXT   DOC    -
 EXT   H      -
 EXTHDR OBJ   - Files used to create user Editor macros
 EXTHDRP  OBJ -
 SKEL  C      -
 SKEL  DEF    -

 (15 Files)

 Disk 9 of 9: Startup Source Code

 DOS       <DIR>
 OS2       <DIR>
 PATCH32   <DIR>
 BRKCTL   INC
 CHKSTK   ASM
 CHKSUM   ASM
 CMACROS  INC
 CRT0FP   ASM
 FMSGHDR  ASM
 MAKEFILE
 MSDOS    H
 MSDOS    INC
 NULBODY  C
 README   DOC
 REGISTER
 SETARGV  ASM
 STARTUP  BAT
 VERSION  INC
 WILD  C

 (16 Files)

 \DOS Subdirectory

 CRT0  ASM
 CRT0DAT  ASM
 CRT0MSG  ASM
 EXECMSG  ASM
 NMSGHDR  ASM
 NULBODY  LNK
 STDALLOC ASM
 STDARGV  ASM
 STDENVP  ASM

 (9 Files)

 \OS2 Subdirectory

 CRT0  ASM
 CRT0DAT  ASM
 CRT0MSG  ASM
 EXECMSG  ASM
 NMSGHDR  ASM
 NULBODY  LNK
 STDALLOC ASM
 STDARGV  ASM
 STDENVP  ASM

 (9 Files)

 \PATCH32 Subdirectory

 PATCH87  DOC
 PATCH87  EXE
 SETRHS   EXE
 RMRHS    EXE
 STKPAT   BAT
 STKPAT   SCR
 PTRACE87 PAT
 PATCH320 DOC
 OS2PATCH EXE
 OS2PATCH DOC

 (10 Files)

 3-1/2" Disk Layout

 The four 3-1/2" disks combine the 5-1/4" disks as follows:

 Disk 1:  Setup, Compiler, and Utilities
 Disk 2:  Examples and Library
 Disk 3:  Microsoft CodeView(R) for MS-DOS and OS/2
 Disk 4:  Microsoft Editor and Startup Source Code


 116. Pascal 4.00 README.DOC: Introduction to README.DOC

 Product Version(s): 4.00   | 4.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified: 26-SEP-1988    ArticleIdent: Q33235

 The following information was taken from the Pascal Version 4.00
 README.DOC file.

 README.DOC (C) Copyright Microsoft(R) Corporation, 1987, 1988

 This file contains information about Version 4.0 of the Microsoft
 Pascal compiler, libraries, and utilities. Microsoft updates its
 documentation when it is reprinted, so you may find that some of the
 information in this on-line file has already been included in your
 manuals.

 NOTE

 Current information about low-level implementation details can be
 found in the Microsoft Mixed-Language Programming Guide and the
 Microsoft CodeView(R) and Utilities manual. These manuals take
 precedence over sections in older manuals.


 117. Pascal 4.00 README.DOC: Reporting Compiler

 Product Version(s): 4.00   | 4.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified: 26-SEP-1988    ArticleIdent: Q33236

 The following information was taken from the Pascal Version 4.00
 README.DOC file.

 README.DOC (C) Copyright Microsoft(R) Corporation, 1987, 1988

 Reporting Compiler Problems

 When reporting problems with the compiler, please first reduce the
 program causing the problem to the smallest program that causes the
 error. Also, 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 PL command).

 The version of DOS you are running (use the DOS VER command).

 Your system configuration (which machine, total memory, 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.

 Providing this information will help us solve your problem quickly.


 118. The Correct Syntax for Forward Referencing a Function

 Product Version(s): 3.3x 4.00 | 4.00
 Operating System:   MS-DOS    | OS/2
 Flags: ENDUSER |
 Last Modified: 18-AUG-1988    ArticleIdent: Q33397

 Question:
    What is the correct syntax for forward referencing a function in
 Pascal? Forward referencing is necessary if you are doing a recursive
 routine of the following form:

 subrt A
     call B        (* Notice B is undefined at this point *)

 subrt B
     call A

 BEGIN (* Main program *)
     call A
 END.

 Response:
    Below is a sample program that contains the structure described
 above. Pascal must know about all items before it uses them, which is
 why it is necessary to use the "forward" keyword.
    The following is a sample program:

 program rec (input, output) ;

 var
     a: integer ;

 (* Forward Reference *)
 function RecurB ( a:integer ):integer ; forward ;

 (*--------------------------------------------------------*)

 function RecurA ( a:integer ):integer ;

 begin
     if a = 1 then
         return
     else
         RecurA := RecurB ( a ) ;
 end ;

 (*--------------------------------------------------------*)

 (* Note Commented parameter list will avoid a warning     **
 ** about the forward declaration already being made       *)

 function RecurB (* ( a:integer ):integer *) ;

 begin
     RecurB := RecurA ( a-1 )  ;
 end ;

 (*--------------------------------------------------------*)

 BEGIN (* Main program *)
     a := RecurA ( 5 ) ;
     write (' a = ',a ) ;
 END.


 119. Pascal 4.00 README.DOC: General Notes

 Product Version(s): 4.00   | 4.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified: 26-SEP-1988    ArticleIdent: Q33238

 The following information was taken from the Pascal Version 4.00
 README.DOC file.

 README.DOC (C) Copyright Microsoft(R) Corporation, 1987, 1988

 General Notes

 SETUP

 Using the SETUP program is optional. You may want to copy the compiler
 files to your disk and use the MAKELIB program on the Pascal Library 1
 Disk (rather than SETUP) to create the required libraries.

 If you set up for dual-mode operation, remember that you must use
 either the /Lr (real mode) or /Lp (protected mode) switch on the PL
 command line.

 You can use the SETUP program to create additional libraries by
 using the /L option. When you run SETUP with the /L option, SETUP
 only takes you through the questions required to create a library.


 120. Pascal 4.00 README.DOC: OS/2 Systems Support

 Product Version(s): 4.00   | 4.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified: 26-SEP-1988    ArticleIdent: Q33239

 The following information was taken from the Pascal Version 4.00
 README.DOC file.

 README.DOC (C) Copyright Microsoft(R) Corporation, 1987, 1988

 OS/2 Systems Support

 PASCAL 4.0 now supports OS/2. The compiler runs under both OS/2 and
 DOS, and applications may be linked to run under either OS/2 or DOS.
 You may bind an OS/2 program so it runs under either protected-mode
 OS/2 or real-mode OS/2 and DOS. Chapter 2 of the update tells you how
 to set up for both operating systems. Creating both protected-mode
 and bound programs is described in Chapter 3, "OS/2 Systems Support,"
 of the update.


 121. Pascal 4.00 README.DOC: Floating-Point Operations

 Product Version(s): 4.00   | 4.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified: 19-AUG-1988    ArticleIdent: Q33269

    The following information was taken from the Pascal Version 4.00
 README.DOC file.

 Floating-Point Operations under MS-DOS 3.2
    This information is important only if your system has ALL of the
 following characteristics:

    1. You use Microsoft DOS (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 on the distribution disks)
       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:

    7. Install the DOS patch by entering the following command:

       PATCH87 /F

     WARNING: If you experience any disk errors during steps 2 through
 7, do NOT proceed with step 8. Reboot from your hard disk and repeat
 the entire process.
    8. 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:
    9. The DOS patch has been installed. Reboot the system.



 122. Pascal 4.00 README.DOC: Setting Error Level

 Product Version(s): 4.00   | 4.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified: 19-AUG-1988    ArticleIdent: Q33276

    The following information was taken from the Pascal Version 4.00
 README.DOC file.

 README.DOC (C) Copyright Microsoft(R) Corporation, 1987, 1988
 Setting Error Level
    The PL driver includes a switch, /w, that sets the error- return
 threshold at which PL stops execution. For example, the following
 command line compiles AVERAGES.PAS with an error return threshold of 1
 (the colon (:) is optional):

    PL /w:1 AVERAGES.PAS

    Compiler warning errors are in the range 1-3.  Compiler hard errors
 are greater than 3.  If the compiler returns an error GREATER than the
 threshold you specify, PL terminates.  The default level is 3.  That
 is, PL terminates only for hard errors, not warnings. The previous
 example causes PL to terminate if there is a warning message.



 123. Pascal 4.00 README.DOC: INCLUDE

 Product Version(s): 4.00   | 4.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified: 19-AUG-1988    ArticleIdent: Q33277

    The following information was taken from the Pascal Version 4.00
 README.DOC file.

 INCLUDE
    By default, PL looks for include files in the directory specified
 by the INCLUDE environment variable. You must set this variable: SETUP
 does not create a default setting in the NEW-VARS.BAT file.



 124. Pascal 4.00 README.DOC: Stack Size

 Product Version(s): 4.00   | 4.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified: 19-AUG-1988    ArticleIdent: Q33278

    The following information was taken from the Pascal Version 4.00
 README.DOC file.

 Stack Size
    Pascal programs compiled for use under OS/2 have 256 fewer bytes
 allocated to the stack.  The 256 bytes are reserved to provide for
 OS/2's additional stack use.



 125. Pascal 4.00 README.DOC: LMULOK

 Product Version(s): 4.00   | 4.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified: 19-AUG-1988    ArticleIdent: Q33279

   The following information was taken from the Pascal Version 4.00
 README.DOC file.

 LMULOK
    Results calculated when an overflow occurs (LMULOK returns FALSE)
 may be inaccurate because the calculation halts when the overflow is
 detected.



 126. Pascal 4.00 README.DOC: $rom Metacommand

 Product Version(s): 4.00   | 4.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified: 26-SEP-1988    ArticleIdent: Q33280

    The following information was taken from the Pascal Version 4.00
 README.DOC file.

 $rom Metacommand
    The $rom metacommand generates an error when used with a VALUE
 section.



 127. Pascal 4.00 README.DOC: Making OS/2 Function Calls

 Product Version(s): 4.00   | 4.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified: 30-SEP-1988    ArticleIdent: Q33281

 The following information was taken from the Pascal Version 4.00
 README.DOC file.

 Making OS/2 Function Calls

 Pascal Version 4.0 includes header files containing function,
 procedure, and data declarations for OS/2 function calls. The
 demonstration program SORTDEMO.PAS shows a use of the header files and
 contains numerous examples of OS/2 function calls. The main header
 file is OS2.INT, which in turn uses several other header files. See
 the PACKING.LST file for the location of the header files and of the
 SORTDEMO.PAS program.

 Your program only needs to include the OS2.INT file: OS2.INT
 automatically includes the other files.

 By defining specific constants you can include some or all of the
 various declarations. These constants are described at the beginning
 of each header file. For example, the following fragment would include
 only the KBD and VIO definitions:

 CONST
         INCL_KBD = 1;
         INCL_VIO = 1;
         INCL_NOCOM = 1;  (* Do not include default
 declarations. *)

 (* $include:'os2.int' *)

 The names in the header files match the names used in the OS/2
 manuals. See the MS OS/2 1.0 Programmer's Reference for detailed
 information about each function.

 Because the Pascal run-time routines are not reentrant, OS/2 functions
 involving multiple threads or requiring reentrancy cannot be safely
 called from Pascal without extensive additional programming. (You may
 write your own reentrant libraries, or you may use semaphores to
 control library access--these are both advanced techniques which
 Microsoft does not support.) Definitions for these functions are
 included for completeness and for the advanced programmer. The OS/2
 functions that use multiple threads or require reentrancy include the
 following:

 DOSCREATETHREAD
 DOSRESUMETHREAD
 DOSSUSPENDTHREAD
 DOSSETSIGHANDLER
 DOSSETVEC
 DOSMONOPEN
 DOSMONCLOSE
 DOSMONREAD
 DOSMONWRITE
 DOSMONREG


 128. Pascal 4.00 README.DOC: New Error Message

 Product Version(s): 4.00   | 4.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified: 19-AUG-1988    ArticleIdent: Q33282

    The following information was taken from the Pascal Version 4.00
 README.DOC file.

 New Error Message 380 - Stack or var with SS <> DS
    An attempt is being made to address a stack variable with adr or ^
 when $windows+ or $stackseg+ is set. These metacommands make SS not
 equal to DS so short addresses (adr or ^) cannot completely reference
 stack variable parameters.



 129. Pascal 4.00 README.DOC: CodeView Using the 7 Command

 Product Version(s): 4.00   | 4.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified: 19-AUG-1988    ArticleIdent: Q33283

   The following information was taken from the Pascal Version 4.00
 README.DOC file.

 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.



 130. Pascal 4.00 README.DOC: Note for Window Developers

 Product Version(s): 4.00
 Operating System:   MS-DOS
 Flags: ENDUSER | appnote SP0284
 Last Modified: 14-DEC-1990    ArticleIdent: Q33284

 The following information was taken from the Microsoft Pascal version
 4.00 README.DOC file. To obtain the updated versions of WIN87EM.EXE
 and WIN87EM.LIB mentioned below, contact Microsoft Product Support
 Services and ask for the application note (number SP0284) "Updated
 WIN87EM.* for Pascal Version 4.00". Please specify which disk size you
 would like, 5.25-inch or 3.5-inch.

 Excerpt from Pascal 4.00 README.DOC
 -----------------------------------

 Note for Windows Developers

 The STACK segment is no longer defined in object files produced by the
 Pascal compiler. It has also been removed from all of the run-time
 modules except ENTX6L.

 This was done to facilitate user declaration of stack size for
 Windows.

 The STACK segment is defined in the module ENTX6L for MS-DOS and
 5ENTX6L for OS/2.

 SETUP builds a library containing (5)ENTX6L (non-Windows) or (5)ENTX6W
 (Windows).

 Applications linking with the Pascal library containing (5)ENTX6W in
 place of (5)ENTX6L must specify stack size with the /STACK: link
 switch or in a .DEF file. (If this is not done, the application will
 get a zero size stack).

 If your Windows programs use the emulator library (LIBPASE.LIB), you
 need to make a modified version of PASLIBW.LIB using updated versions
 of WIN87EM.EXE and WIN87EM.LIB. Call Microsoft Product Support to get
 the updated files. To create the modified library, use the LIB utility
 by typing the following command:

    lib paslibw-noemstar+win87em.lib,,paslibwe.lib

 This command creates a library, PASLIBWE.LIB, to use instead of
 PASLIBW.LIB for applications linking with the emulator library,
 LIBPASE.LIB.


 131. Pascal 4.00 README.DOC: Corrections to the Update

 Product Version(s): 4.00   | 4.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | docerr
 Last Modified: 26-SEP-1988    ArticleIdent: Q33285

 The following information was taken from the Pascal Version 4.00
 README.DOC file.

 Corrections to the Update

 p. 8 In Section 1.5.2, \PWORK should be \WORK.

 p. 9 If you use SETUP to install Pascal in a subdirectory, SETUP
 places the files mentioned in Section 1.5.3, "Environment Variable and
 Configuration Files," in the WORK directory under the specified
 subdirectory.

 p. 16 The line reading

 @PROG=PL /Lr AVERAGES.PAS

 should read

 PL /Lr AVERAGES.PAS

 p. 53 The correct name of the LVARSTK.OBJ file mentioned in  6.4.3 is
 LVARSTCK.OBJ.

 p. 63 The use of "module" in Section 7.3, "Program Module,"is
 misleading. Windows development using multiple Pascal source files
 requires the use of units, not modules. Pascal units generate the
 implementation and interface code required under Windows; modules do
 not. See pp. 300-311, "Units," in the Pascal Language Reference Manual
 for information about Pascal units.


 132. Pascal 4.00 README.DOC: Notes on CodeView and Utilities

 Product Version(s): 4.00   | 4.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified: 26-SEP-1988    ArticleIdent: Q33286

 The following information was taken from the Pascal Version 4.00
 README.DOC file.

 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.0 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.


 133. Pascal 4.00 README.DOC: CodeView New Command-Line Option

 Product Version(s):
 Operating System:   4.00   | 4.00
 Flags: MS-DOS | OS/2
 Last Modified: 26-SEP-1988    ArticleIdent: Q33287
 ENDUSER |

 The following information was taken from the Pascal Version 4.00
 README.DOC file.

 Microsoft CodeView 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.


 134. Pascal 4.00 README.DOC: CodeView CONFIG.SYS

 Product Version(s): 4.00   | 4.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified: 18-AUG-1988    ArticleIdent: Q33288

    The following information was taken from the Pascal Version 4.00
 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 or CONFIG.OS2 file:

    IOPL=YES



 135. Pascal 4.00 README.DOC: Using Real-Mode Debugger

 Product Version(s): 4.00   | 4.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified: 18-AUG-1988    ArticleIdent: Q33289

    The following information was taken from the Pascal Version 4.00
 README.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.


 136. Pascal 4.00 README.DOC: Using Real-Mode with BIND

 Product Version(s): 4.00   | 4.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified: 22-AUG-1988    ArticleIdent: Q33433

    The following information was taken from the Pascal Version 4.00
 README.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.


 137. Pascal 4.00 README.DOC: Stack Trace Command

 Product Version(s): 4.00   | 4.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified: 22-AUG-1988    ArticleIdent: Q33434

    The following information was taken from the Pascal Version 4.00
 README.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).



 138. Pascal 4.00 README.DOC: Error Messages in Pascal

 Product Version(s): 4.00   | 4.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified: 22-AUG-1988    ArticleIdent: Q33435

    The following information was taken from the Pascal Version 4.00
 README.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 and records
 could not be displayed. With current version of the debugger, only
 enumerated types 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.


 139. Pascal 4.00 README.DOC: Pascal Programs: PAS1 /Zz TEST;

 Product Version(s): 4.00   | 4.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | docerr
 Last Modified: 19-AUG-1988    ArticleIdent: Q33436

    The following information was taken from the Pascal Version 4.00
 README.DOC file.

 Microsoft Pascal Programs
    The Pascal example on pg. 61 of the Microsoft CodeView and
 Utilities manual should read

         PAS1 /Zz TEST;

 rather than

         PAS1 /Zi TEST;



 140. Pascal 4.00 README.DOC: Exit Codes for Utilities: LINK

 Product Version(s): 4.00   | 4.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified: 22-AUG-1988    ArticleIdent: Q33437

    The following information was taken from the Pascal Version 4.00
 README.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.



 141. Pascal 4.00 README.DOC: LIB, EXEPACK, EXEMOD, MAKE, SETENV

 Product Version(s): 4.00   | 4.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified: 22-AUG-1988    ArticleIdent: Q33438

    The following information was taken from the Pascal Version 4.00
 README.DOC file.

 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.



 142. Pascal 4.00 README.DOC: New LINK Error Messages

 Product Version(s): 4.00   | 4.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified: 22-AUG-1988    ArticleIdent: Q33440

    The following information was taken from the Pascal Version 4.00
 README.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
    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).



 143. Pascal 4.00 README.DOC: LIB New Option

 Product Version(s): 4.00   | 4.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified: 19-AUG-1988    ArticleIdent: Q33441

    The following information was taken from the Pascal Version 4.00
 README.DOC file.

 Microsoft Library Manager (LIB)
 New Option
    There is a new option for LIB:  /NOIGNORECASE (abbreviated as
 /NOI). 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 notadd
 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).


 144. Pascal 4.00 README.DOC: Changed LIB Error Message

 Product Version(s): 4.00   | 4.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified: 19-AUG-1988    ArticleIdent: Q33442

    The following information was taken from the Pascal Version 4.00
 README.DOC file.

 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



 145. Pascal 4.00 README.DOC: MAKE Minus Sign in Description Files

 Product Version(s): 4.00   | 4.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified: 19-AUG-1988    ArticleIdent: Q33443

    The following information was taken from the Pascal Version 4.00
 README.DOC file.

 Microsoft Program Maintenance Utility (MAKE)
 Minus Sign in Description File
     The documentation is in error when it says that a minus sign at
 the beginning of a description block causes errors to be ignored
 (CodeView and Utilities manual, p. 311).  The minus sign cannot be
 used.



 146. Pascal 4.00 README.DOC: MAKE New Error Message

 Product Version(s): 4.00   | 4.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified: 19-AUG-1988    ArticleIdent: Q33444

    The following information was taken from the Pascal Version 4.00
 README.DOC file.

 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 may define the same macro in both the TOOLS.INI and
 the description file.  In such cases, the definition in the TOOLS.INI
 file takes precedence.  You may avoid this problem by copying the
 TOOLS.INI to the same directory as your make file and modifying the
 make section.


 147. Pascal 4.00 README.DOC: MAKE Backslash

 Product Version(s): 4.00   | 4.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified: 19-AUG-1988    ArticleIdent: Q33445

    The following information was taken from the Pascal Version 4.00
 README.DOC file.

 Backslash (\) as Continuation Character
    Note that MAKE considers a backslash immediately followed by a
 new-linecharacter to be a continuation character.  When it finds this
 combinationin a description file, MAKE concatenates the line
 immediately followingthe combination with the line where the
 combination appears.If you define a macro that ends in a backslash,
 make sure that you put aspace after the terminating backslash.For
 example, if you want to definemacros for the path C:\SRC\BIN and
 C:\SRC\LIB, you must use the formatillustrated
 below:BINPATH=C:\SRC\BIN\


 148. Pascal 4.00 README.DOC: STDERR Redirection Utility

 Product Version(s): 4.00   | 4.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified: 19-AUG-1988    ArticleIdent: Q33446

    The following information was taken from the Pascal Version 4.00
 README.DOC file.

 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.


 149. Pascal 4.00 README.DOC: C Naming Conventions

 Product Version(s): 4.00   | 4.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified: 18-AUG-1988    ArticleIdent: Q33494

    The following information was taken from the Pascal Version 4.00
 README.DOC file.

 Mixed-Language Programming C Naming Conventions
    C recognizes the first 31 characters of a symbolic name.



 150. Pascal 4.00 README.DOC: Pascal Function Fact

 Product Version(s): 4.00   | 4.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified: 18-AUG-1988    ArticleIdent: Q33495

    The following information was taken from the Pascal Version 4.00
 README.DOC file.

 Pascal Function Fact
    The following line in the Pascal function Fact on pages 30, 44, and
 57 in the Mixed-Language Programming Guide is incorrect:

    Fact := Fact * n;

    The line should read as follows:

    Fact := result(Fact) * n;



 151. Pascal 4.00 README.DOC: Mixed-Language Accessing Parameter

 Product Version(s): 4.00   | 4.00
 Operating System:   MMS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified: 18-AUG-1988    ArticleIdent: Q33496

    The following information was taken from the Pascal Version 4.00
 README.DOC file.

 Enhanced Error Handling 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.



 152. Pascal 4.00 PATCH87.DOC: Patching MS-DOS Version 3.20

 Product Version(s): 4.00   | 4.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified: 18-AUG-1988    ArticleIdent: Q33554

    The following information was taken from the Pascal Version 4.00
 PATCH87.DOC file.

 PATCH87.DOC File
 Notes on patching MS-DOS(R) Version 3.20 (C) Copyright Microsoft
 Corporation, 1988
    Version 3.20 of MS-DOS(R) contains a bug that can cause unexpected
 results in programs that use floating-point math. This file explains
 how to eliminate that problem by using PATCH87.EXE, a program included
 in this release.
    Note that IBM(R) PC-DOS 3.20 contains another, different
 floating-point bug. The README.DOC file for this release tells you
 where to find more information about installing a patch for that bug.
 If you use any version of DOS 3.20 other than IBM PC-DOS 3.20 or
 MS-DOS 3.20, contact your hardware manufacturer to determine whether
 the problem exists in your version.

 Do I Need to Use This Program?
    You do not need to read any further unless 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) 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

          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.

    5. Follow the procedure described in the next section if the
       program tells you that you need to install the DOS patch, and that
       it can be done.

       NOTE: The floating-point problem has been eliminated in versions
       of MS-DOS higher than 3.20. This includes MS-DOS versions 3.21 and
       3.30.

 If You Need to Install the Patch
    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:

    7. Install the DOS patch by entering the following
       command:

       PATCH87 /F

          WARNING: If you experience any disk errors during steps 2
       through 7, do NOT proceed with step 8. Reboot from your hard
       disk and repeat the entire process.

    8. 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:

       This installs the DOS patch.
    9. Reboot the system.


 153. Pascal 4.00 README.DOC: Mixed-Language BASIC

 Product Version(s): 4.00   | 4.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified: 18-AUG-1988    ArticleIdent: Q33498

    The following information was taken from the Pascal Version 4.00
 README.DOC file.

 BASIC Return Values
    BASIC functions use the FORTRAN/Pascal conventions, rather than the
 C conventions, for receiving return values.



 154. Pascal 4.00 README.DOC: Passing C Strings to BASIC

 Product Version(s): 4.00   | 4.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified: 18-AUG-1988    ArticleIdent: Q33499

    The following information was taken from the Pascal Version 4.00
 README.DOC file.

 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



 155. Pascal 4.00 README.DOC: Mixed-Language BASIC Array

 Product Version(s): 4.00   | 4.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified: 18-AUG-1988    ArticleIdent: Q33500

    The following information was taken from the Pascal Version 4.00
 README.DOC file.

 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)



 156. Pascal 4.00 README.DOC: Linking Mixed-Language Programs

 Product Version(s): 4.00   | 4.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified: 26-SEP-1988    ArticleIdent: Q33501

 The following information was taken from the Pascal Version 4.00
 README.DOC file.

 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 Version 5.10 of the
 Microsoft C Optimizing Compiler and this version of Pascal.)

 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 /NOE objs,,,LLIBC7.LIB LLIBFOR7.LIB;

 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. Other wise, the
 C 5.1 library should be listed first. (Or, if you are using C 4.0 with
 FORTRAN 4.0 or later, the FORTRAN library should be listed first.) For
 best results, using large-memory-model C is suggested.


 157. Pascal 4.00 README.DOC: BIND Utility Specifying Libraries

 Product Version(s): 4.00   | 4.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified: 26-SEP-1988    ArticleIdent: Q33502

 The following information was taken from the Pascal Version 4.00
 README.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 MYPROG.EXE \LIB\DOSCALLS.LIB


 158. Pascal 4.00 README.DOC: Using BIND with Packed Files

 Product Version(s): 4.00   | 4.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified: 18-AUG-1988    ArticleIdent: Q33503

    The following information was taken from the Pascal Version 4.00
 README.DOC file.

 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.



 159. Pascal 4.00 README.DOC: Running Bound Files with DOS 2.1

 Product Version(s): 4.00   | 4.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified: 26-SEP-1988    ArticleIdent: Q33504

 The following information was taken from the Pascal Version 4.00
 README.DOC file.

 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.


 160. Pascal 4.00 README.DOC: Mix-Language Linking with MASM Files

 Product Version(s): 4.00   | 4.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified: 18-AUG-1988    ArticleIdent: Q33505

    The following information was taken from the Pascal Version 4.00
 README.DOC file.

 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.


 161. Pascal 4.00 README.DOC: Editor and Linking

 Product Version(s): 4.00   | 4.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified: 18-AUG-1988    ArticleIdent: Q33534

    The following information was taken from the Pascal Version 4.00
 README.DOC file.

 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.


 162. Pascal 4.00 README.DOC: Incremental Linker Fatal

 Product Version(s): 4.00   | 4.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified: 18-AUG-1988    ArticleIdent: Q33535

    The following information was taken from the Pascal Version 4.00
 README.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.



 163. Pascal 4.00 README.DOC: Incremental Linker

 Product Version(s): 4.00   | 4.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified: 18-AUG-1988    ArticleIdent: Q33536

    The following information was taken from the Pascal Version 4.00
 README.DOC file.

 Incremental Violations (ILINK errors)
    These errors cause a full link to occur if the -e option is used
 and -i is not used, 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.


 164. Pascal 4.00 README.DOC: Incremental Linker Warning

 Product Version(s): 4.00   | 4.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified: 26-SEP-1988    ArticleIdent: Q33537

 The following information was taken from the Pascal Version 4.00
 README.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.


 165. Passing Pascal Function or Procedure Pointers to C Function

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

    Microsoft Pascal has the procedure and function address types
 adsproc and adsfunc for use in mixed-language programming. Pascal
 cannot call a procedure or function by their pointers; however, C can,
 as the following corrected and modified example of Page 141 of the
 "Microsoft Pascal 4.0 Compiler User's Guide" shows.

    The C module must be compiled for medium or large model with either
 the /AM or /AL compiler switches, respectively. The linker options
 /NOE and /NOD should be used, and the C library should be linked in
 first to prevent multiple-symbol definition errors.
    Pascal only can obtain the address of external functions or
 procedures using the ads operator. In Pascal, the ads operator will
 not obtain the address of a procedure or function within the current
 modules.
    Below is the main Pascal program module. It contains the corrected
 version of the Pascal user's guide example for addressing procedures and
 functions.
    The example passes procedure and function pointers obtained by the
 ads operator to the C function. C then calls the procedure and
 function by their pointers.
    Note that Pascal cannot call a routine by its pointer. Pascal can
 obtain the address of an external routine, but it cannot obtain the
 address of a routine within the current module with the ads or adr
 operators, so the routines must be declared "extern" here and reside
 in a different module.
    You must link with /NOE and /NOD options, and first specify C
 run-time library to prevent multiple-symbol definition linker
 errors.
    The following is the main Pascal program module:

 {Originally was "program p(output);". Could formally include "input" for
  readln in function pfunc, but not actually required in this example.}

 program p(input,output);

     {Routines must be external for Pascal to obtain the addresses}
     procedure pproc(i : integer); extern;
     function  pfunc : integer; extern;

     {This procedure declaration requires ";" here v}
     procedure cproc(ap: adsproc; af: adsfunc ) [c]; extern;

 begin {begin main Pascal program p}
     cproc( ads pproc, ads pfunc); {originally missing ads operators}
 end.  {end main Pascal program p}

 {--------- External Pascal Module Defining Procedure and Function ----------}

 { From corrected and modified example in "Microsoft Pascal 4.0 Compiler
   User's Guide" Page 141. The routines below cannot be in the same module
   that uses the ads operator to obtain their addresses.
 }

 module SecondPascalModule;

 procedure pproc( i : integer );
 begin
     writeln('In Pascal procedure pproc within second Pascal module.');
     writeln('Pascal proc integer = ', i );
 end;

 function pfunc : integer;
 var
     i : integer;
 begin
     write('Please Enter an integer for the function return value : ');
     readln( i );
     writeln;
     pfunc := i;
 end;

 end. {SecondPascalModule}

 {-------- C Function to Receive Pointers and Call Pascal Routines by them --}

 /* C function cproc called by Pascal main program. printf the address of the
  Pascal procedure and function from the second Pascal module, then call them
  by their function pointers. Note that the Pascal procedure pproc has one
  integer argument of 7 in this example, while the Pascal function pfunc has
  no arguments but returns an integer.

  Compile this with /AM or /AL. Link with /NOE /NOD and specify the
  C libraries first to avoid multiple symbol definitions.
 */

 #include <stdio.h>

 /* Prototype for function cproc. Do not specify argument to pproc here. */
 void cproc( void (pascal * pproc)(), int (pascal * pfunc)() );

 void cproc (void(pascal * pproc)(), int(pascal * pfunc)()) {
     int ReturnCode;

     printf("\nIn cproc(); address of pproc at %p, pfunc at %p\n",pproc,pfunc)
     printf("\nExecute the Pascal procedure:\n");
     (*pproc)(7);
     printf("\nExecute the Pascal function :\n");
     ReturnCode = (*pfunc)();
     printf("Integer Entered in Pascal function was %d. Bye!\n",ReturnCode);
     }


 166. Pascal 4.00 README.DOC: Installing Editor

 Product Version(s): 4.00   | 4.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified: 18-AUG-1988    ArticleIdent: Q33539

    The following information was taken from the Pascal Version 4.00
 README.DOC file.

 Microsoft Editor
 Installing the Editor
    The Pascal SETUP program installs the Microsoft Editor on your hard
 disk if you request it during setup.


 167. Pascal 4.00 README.DOC: Editor Keystroke

 Product Version(s): 4.00   | 4.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified: 18-AUG-1988    ArticleIdent: Q33540

    The following information was taken from the Pascal Version 4.00
 README.DOC file.

 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.



 168. Pascal 4.00 README.DOC: Editor Compile Function

 Product Version(s): 4.00   | 4.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified: 26-SEP-1988    ArticleIdent: Q33541

 The following information was taken from the Pascal Version 4.00
 README.DOC file.

 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.


 169. Pascal 4.00 README.DOC: Editor Setfile Function

 Product Version(s): 4.00   | 4.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified: 18-AUG-1988    ArticleIdent: Q33542

    The following information was taken from the Pascal Version 4.00
 README.DOC file.

 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 "$INIT:tools.ini" Setfile



 170. Pascal 4.00 README.DOC: Editor and Entering Strings in Macros

 Product Version(s): 4.00   | 4.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified: 26-SEP-1988    ArticleIdent: Q33543

 The following information was taken from the Pascal Version 4.00
 README.DOC file.

 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.


 171. Pascal 4.00 README.DOC: Editor and Using Text Switches

 Product Version(s): 4.00   | 4.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified: 18-AUG-1988    ArticleIdent: Q33544

    The following information was taken from the Pascal
 Version 4.00 README.DOC file.

 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".



 172. Pascal 4.00 README.DOC: Editor and the Filetab Switch

 Product Version(s): 4.00   | 4.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified: 18-AUG-1988    ArticleIdent: Q33545

    The following information was taken from the Pascal Version 4.00
 README.DOC file.

 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.



 173. Pascal 4.00 README.DOC: Editor and Linking Extensions

 Product Version(s): 4.00   | 4.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified: 18-AUG-1988    ArticleIdent: Q33546

    The following information was taken from the Pascal Version 4.00
 README.DOC file.

 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.


 174. PL /S And /link Options Together Result in LINK Error L1004

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

    A Pascal Version 4.00 command line using both the /S (Stack size)
 and /link options, such as

    PL /S500 hello.pas /link

 will result in bad input for the following linker's .MAP file prompt
 and linker error:

    LINK: fatal error L1004: STACK:500HHELLO.PAS: invalid numeric value

    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.

    The bad input at the .MAP prompt will consist of ASCII character 2
 (a dark smiley face on the screen of IBM PCs and compatibles) followed
 by an extra copy of the first non-blank character following "/S500".
 The link error message does not display the ASCII 2.
    Note that with the above PL command line, the first non-blank
 character following the /S string is the "h" in "hello.pas", which is
 doubled in both the .MAP file prompt and the link error message. If a
 blank had occurred between "/S" and "500", the "5" would have been
 doubled following ASCII 2 at the .MAP prompt.
    To work around this problem, do not use /S and /link together. Use
 the linker switch /ST:<stack_size_in_decimal> either after /link or
 when linking separately. Or you may use the EXEMOD utility with its
 /Stack <stack_size_in_hex> option on a successfully linked .EXE file.


 175. Pascal 4.00 PATCH320.DOC: Patching IBM PC-DOS Version 3.20

 Product Version(s): 4.00   | 4.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified: 18-AUG-1988    ArticleIdent: Q33555

    The following information was taken from the Pascal Version 4.00
 PATCH320.DOC file.

 PATCH320.DOC File
 Notes on patching IBM(R) PC-DOS Version 3.20 (C) Copyright Microsoft
 Corporation, 1988
    Version 3.20 of IBM(R) PC-DOS contains a bug that can cause
 unexpected results in programs that generate floating-point
 exceptions. This file explains how to install a small patch in DOS to
 eliminate the problem.
    It is especially important to install this patch if you wish to use
 the C run-time routine signal with the SIGFPE parameter, since that
 routine does not work correctly in the unpatched version of IBM PC-DOS
 3.20. IBM Corporation also supplies a patch to eliminate this problem.
    Note that MS-DOS(R) Version 3.20 contains another, different
 floating-point bug. The README.DOC file for this release tells you
 where to find more information about installing a patch for that bug.
 If you use any version of DOS 3.20 other than IBM PC-DOS 3.20 or
 MS-DOS 3.20, contact your hardware manufacturer to determine whether
 the problem exists in your version.
    You can install the DOS patch for IBM PC-DOS 3.20 by following
 these 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 the files IBMDOS.COM and IBMBIO.COM
       to the new disk. For example, if you boot from drive C:, you could
       use these commands:

       C:
       SYS A:

    3. Use the COPY command to copy the files COMMAND.COM, SYS.COM,
       and DEBUG.COM to the new disk.
    4. Use the COPY command to copy the files STKPAT.BAT, STKPAT.SCR,
       RMRHS.EXE, and SETRHS.EXE from the \PATCH directory of your
       hard-disk drive to the new disk.
    5. Reboot your system from the floppy disk that you
       prepared in steps 1-4.
    6. Run the STKPAT.BAT file to patch the IBMBIO.COM file on the new
       disk.
    7. Use the SYS command to transfer the patch from the floppy
       disk other Version 3.20 disk. For example, if you normally
       boot from drive C:, you would enter these commands to transfer
       the patched DOS to your hard-disk drive:

       to any A:
       SYS C:

       This installs the patch.
    8. Reboot your system as you normally do.


 176. Pascal 4.00 OS2PATCH.DOC: Patching Microsoft OS/2

 Product Version(s): 4.00   | 4.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified: 18-AUG-1988    ArticleIdent: Q33556

    The following information was taken from the Pascal Version 4.00
 OS2PATCH.DOC file.

 OS2PATCH.DOC File
 Information on a Patch for Microsoft Operating
 System/2 (MS(R) OS/2) Version 1.0 (C) Copyright Microsoft Corporation,
 1987, 1988
    This file describes the procedure for installing a patch in
 Microsoft(R) Operating System/2 OS/2 (MS(R) OS/2) Version 1.0 so that
 you can use the 7 command of the Microsoft CodeView(R) debugger in
 OS/2 protected mode.
    If you are using protected mode in OS/2 Version 1.0, and you have a
 math coprocessor, then you need to use a patch before you can use the
 CVP 7 command in CodeView. 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 that it
       is inserted in the drive that you boot from.)
    2. Give the following command line at the DOS prompt:

       OS2PATCH /A PTRACE87.PAT

    You may need to give the complete path names for OS2PATCH.EXE and
 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.


 177. Pascal 4.00 Startup Source Code README.DOC

 Product Version(s): 4.00   | 4.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified: 18-AUG-1988    ArticleIdent: Q33557

    The following information was taken from the Pascal Version 4.00
 Startup Source Code README.DOC.

 C Runtime Library Startup Sources
    The directory \startup and its subdirectories contain the files
 necessary for building the startup portion of the C runtime 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 C compiler, and the assembler must be
 in the execution path. MASM 5.0 and C 5.0 or later are required to
 build the startup sources.
    2. doscalls.lib must be in the directory specified by the LIB
 environment variable.
    Startup will create four memory model specific subdirectories
 (i.e., S, M, C, and L) and place the appropriate object files there.
 Under each memory model subdirectory, startup creates two addition
 subdirectories OS2 and DOS where OS specific objects reside.
    The include files stdio.h and ctype.h are required for building the
 startup source file wild.c but are not included on the \startup
 directory because they exist on the directory containing the standard
 include files. A make variable called CINC controls where the makefile
 looks for these include files. STARTUP.BAT sets CINC to the current
 value of the INCLUDE environment variable. This variable should be
 set to the location of the C include files. CINC can also be set in
 the makefile if you wish to run the makefile separately.
    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 S L" will build the small and large model startup objects.
 Startup will then link the objects with a sample C program called
 nulbody.c (consisting of a null main functions) 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. Startup sources written in C have been
 edited with tabstops set to 4.
    The following files are contained in the \startup directory:

    Startup source files (OS independent):

    chkstk.asm
    chksum.asm
    crt0fp.asm
    setargv.asm
    wild.c

    Startup source files (OS specific):
    crt0.asm
    crt0dat.asm
    crt0msg.asm
    execmsg.asm
    nmsghdr.asm
    stdalloc.asm
    stdenvp.asm
    stdargv.asm

    Startup include files:
    brkctl.inc
    cmacros.inc
    msdos.inc
    register.h
    msdos.h
    version.inc

    File count files:
    _file.c
    file2.h

    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.c:     null c program
    nulbody.lnk:   link script for linking null program

    Documentation:

    readme.doc:    information about \startup directory
                   structure and contents

   End


 178. Glockenspiel Turbo Pascal to C Translator Source Code

 Product Version(s): 3.30 3.31 3.32 4.00
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 18-AUG-1988    ArticleIdent: Q33563

    The Irish company Glockenspiel writes the Turbo Pascal to C
 Translator. If you are interested in obtaining the source code, please
 contact Glockenspiel.
    The following is the address and phone number:

    19 Belvedere Place
    Dublin 1

    011-353-1-364515



 179. Pascal 4.00 Compiler Error 380 "Stack or var with SS <> DS"

 Product Version(s): 4.00   | 4.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | docerr
 Last Modified: 26-SEP-1988    ArticleIdent: Q33721

 The Pascal Version 4.00 compiler may issue the following undocumented
 compiler error message:

 Error 380 - Stack or var with SS <> DS

 This error is not listed in the "Microsoft Pascal 4.0 Compiler User's
 Guide"; however, it is noted in the Pascal Version 4.00 README.DOC
 file.

 The the error occurs when attempting to address a stack or near-heap
 variable with the adr or ^ operators when the $windows+ or $stackseg+
 metacommands or equivalent compiler switches are set. The $windows+
 and $stackseg+ metacommands set SS <> DS (Stack Segment not equal to
 Data Segment), and require that the far address (or long address that
 consists of the segment and offset) be obtained for addressing stack
 and near-heap variables.

 The ads operator may be used for addressing data items with both
 the segment and offset as indicated in Pages 73-76 of the Pascal
 user's guide.

 The adr operator is used for obtaining offset addresses only of data
 items within the default data segment or Dgroup. The carrot "^"
 operator is for defining and dereferencing pointers to data items
 allocated on the near (or short) heap within Dgroup by means of the
 New function. Both of these operators assume SS = DS.

 The $windows+ metacommand is equivalent to the PL switch /Pw or the
 PAS1 switch /W, and has the effect of adding initialization and
 cleanup code to Windows applications written in Pascal.


 180. Debug Information Exceeding Segment Bounds, Link Error L1103

 Product Version(s): 4.00   | 4.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | buglist4.00 SR# G880727-1846
 Last Modified: 18-AUG-1988    ArticleIdent: Q33899

 Problem:
    When compiling and linking my large program, which nearly fills the
 64K-byte default data segment with defined data, I receive the linker
 error L1103: "attempt to access data outside segment bounds." Extended
 run-time debugging information has been added to my program by the
 metacommand $debug+, or the PL switch /Pd, or the PAS1 switch /D.
    To avoid error L1103, I do not include extended run-time debugging
 information when the default data segment is almost full.

 Response:
    The linker error L1103 occurs because the extended run-time
 debugging information is added to the 64K default data segment, or
 Dgroup. The addition of this debugging information increases the
 size of Dgroup, which is readily noticeable in the map file. If Dgroup
 is nearly filled with defined data, the debugging information can
 increase the size of Dgroup beyond 64K, which causes linker error
 L1103.
    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.
    The $debug+ metacommand is described in the "Microsoft Pascal 4.0
 Compiler Reference Manual" section 18.2 "Debugging and Error Handling."
 The addition of this debugging information provides the source code
 filename, routine name or main program module name, and line number
 for run-time error messages.
    If you would like to debug programs that have nearly 64K of defined
 data, use the /Zi CodeView information option, which does not store
 any information in Dgroup. This process allows you to use CodeView to
 debug your program without running into any linker problems. Note that
 the CodeView information PL switch /Zi (or PAS1 /Z) is incompatible
 with the extended run-time debugging PL switch /Pd (or PAS1 /D); do
 not compile with both /Zi and /Pd, or /Z and /D.


 181. Check Sum Errors in Pascal Libraries

 Product Version(s): 4.00   | 4.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified: 26-SEP-1988    ArticleIdent: Q34362

    Check Sum errors are generated when a simple Pascal program is
 linked with PLINK86 Version 2.01.
    Microsoft is researching this problem, and will post more
 information as it becomes available.
    The errors occur in the following modules which were reported to
 be associated with PLINK86:

    filf.pas
    strf.pas
    misoe.pas

    These errors occur when using either libpase.lib or libpas7.lib.


 182. PL /FPi Option Is for Coprocessor Math

 Product Version(s): 4.00   | 4.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified: 26-SEP-1988    ArticleIdent: Q33710

 The PL compiler-linker driver option /FPi is for using coprocessor
 math and linking with the combined library LIBPAS7.LIB. The default
 math option is /FPe for emulator math, which will call the library
 LIBPASE.LIB. In C or FORTRAN, /FPi is used for emulator math; /FPi87
 is used for coprocessor math.

 If you are accustomed to Microsoft C or FORTRAN, you may inadvertently
 use /FPi for specifying emulator math with Pascal. If LIBPAS7.LIB is
 not present in the current working directory or a directory specified
 by the LIB environment variable, the linker will issue the following
 warning and prompt:

 LINK: warning L4051: LIBPAS7.LIB: cannot find library
 Enter new file spec:

 Either entering the existing library name LIBPASE or recompiling
 without /FPi allows you to link to the emulator-math library. If you
 do link with LIBPAS7.LIB, your program will require a 80x87
 coprocessor to run correctly.

 Note that if you set up for dual-mode (DOS or OS/2 rear mode, and
 OS/2 protected mode), the actual names for the emulator-math combined
 libraries may be LIBPASER.LIB for real mode or LIBPASEP.LIB for
 protected mode.


 183. PAS1 Switch /Xsymbol Is Not Handled Correctly

 Product Version(s): 4.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | buglist4.00
 Last Modified: 26-SEP-1988    ArticleIdent: Q34935

 Passing the /Xsymbol[=value] switch to PAS1 of the Microsoft
 Pascal Version 4.00 compiler generates a "Line invalid" error.
 This problem only occurs when /X switch precedes the filename.

 For example, if the following is used,

 pas1 /Xabc filename;

 the following error is generated because the filename is not being
 read by pas1:

 Line invalid: ';', start again.
 Source filename [.PAS] :

 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.

 If one or more switches follows the /Xsymbol, it works correctly.

 The following is an example:

 pas1 /Xabc /N filename;

 Also, placing the /X switch after the filename works properly, as
 follows:

 pas1 filename /Xabc ;

 In addition, you can use the PL driver as an alternative (/D switch),
 as follows:

 "pl /Dabc filename.pas"


 184. File Error Trapping when Using lm_lock

 Product Version(s): 3.20 4.00 | 4.00
 Operating System:   MS-DOS    | OS/2
 Flags: ENDUSER |
 Last Modified: 26-SEP-1988    ArticleIdent: Q34971

 In Pascal, the procedure locking() and the TYPE lockmodes have been
 defined to allow you to lock a specific range of records in a DIRECT
 mode file, as follows:

 TYPE            lockmodes = (lm_unlck,lm_lock,lm_nblck,lm_rick,
                 lm_nbrick);

 PROCEDURE locking(VAR f: FCBFQQ; MODE: lockmodes;
                   M,N : INTEGER4);

 When a process is using the lm_lock value of lockmodes in the
 procedure locking (as described on Page 146 of the "Microsoft Pascal
 4.0 Compiler User's Guide"), and it encounters a locked record, it
 will wait for 10 seconds before returning a run-time file-system error
 #16.

 This error is not documented and can be described as a Record
 Locked - share error. The run-time file-system errors are described on
 Pages 257-258 of the user's guide.


 185. Pascal File System Explained

 Product Version(s): 3.32 4.00 | 4.00
 Operating System:   MS-DOS    | OS/2
 Flags: ENDUSER |
 Last Modified: 26-SEP-1988    ArticleIdent: Q35136

 The following information explains the Pascal file system.

 The Pascal file system is similar to, but not compatible with,
 buffered stream files in C. There is a File Control Block (FCB) with a
 file buffer allocated in the near heap when the file is opened. All
 I/O goes from/to the file buffer to the DOS device buffer.

 To flush a file buffer in Pascal, use the CLOSE procedure, or end the
 program normally. There is no buffer flushing routine. Because a
 Pascal FCB has a different record format than a C FILE * struct, you
 cannot use C run-time library routines to try flushing a Pascal FCB.

 Sequential files in Pascal allow reading only if opened by Reset, or
 writing only if opened by Rewrite; however they do not allow both
 reading and writing. Direct files may be both read and written.

 Sequential is the default file mode unless the file mode is explicitly
 specified as in the following:

 FileVar.Mode := direct;

 The following code fragment demonstrates how to setup file error
 trapping for handling I/O errors within your program rather than
 exiting to the operating system:

 var  f : text;
 begin
         assign(f,'afile');
         f.trap := true;
         f.errs := 0;

 After every file I/O operation, you can check f.errs for a non-0
 value. Errors 1-15 are document prior to error 1000 in the back of the
 "Microsoft Pascal Compiler User's Guide." Undocumented error 16
 usually indicates a network file or record sharing violation has
 occurred. Pascal automatically reads the first record of a file when
 it is opened, so do not lock the first record of a file if you want
 other processes to be able to access any records in the file.

 Make sure you reassign zero to f.errs after handling a file error so
 you can detect any future errors.


 186. Calling DOS Interrupt 21 Hex Functions from Pascal

 Product Version(s): 3.3x 4.00 | 4.00
 Operating System:   MS-DOS    | OS/2
 Flags: ENDUSER |
 Last Modified: 26-SEP-1988    ArticleIdent: Q35165

 In Pascal, you may call a subset of the DOS interrupt 21 hex functions
 by means of the DOSXQQ function. DOSXQQ is documented on Pages 161-162
 in Appendix B.1 of the "Microsoft Pascal Compiler User's Guide."

 The DOSXQQ function is documented as passing a byte to the AH register
 and an additional argument to the DX register. The return value from
 DOSXQQ is a byte that corresponds to the DOS function value returned
 in the AL register. By defining the public variables CRCXQQ and CRDXQQ
 as EXTERN, you may use these variables to view the contents of the CX
 and DX registers, respectively, after the DOSXQQ call. CRCXQQ also may
 be used to load CX prior to the DOSXQQ call.


 187. Correction to Page 120 of the Pascal 4.0 Reference Manual

 Product Version(s): 5.10   | 5.10
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | docerr
 Last Modified: 19-AUG-1988    ArticleIdent: Q34578

 The bottom of Page 120 of the "Microsoft Pascal 4.0 Compiler Reference
 Manual" states the following:

 -1..50000   Invalid : becomes 65535..50000 (i.e., -1 is treated as
             65536)

 When converted to a two-byte unsigned word, -1 is treated as 65535
 instead of 65536.

 In addition, the Pascal compiler will issue "Warning 199 Integer Type
 Not Compatible With Word Type" and error "275 Invalid Range" if the
 above range is specified for a type or variable.

 Pascal does not allow integer4 subranges to be specified as constants.
 The 50000 upper bound of the subrange exceeds the maximum signed
 two-byte integer of 32767, so it is converted to an unsigned two-byte
 word type. The unsigned word equivalent of -1 is 65535; consequently
 the subrange -1..50000 apparently would be treated as 65535..50000.
 However, because Pascal does not allow a range to be specified from a
 high value to a lower value, the invalid range error results.


 188. Directory Listing for Pascal 3.32 Distribution Disks

 Product Version(s): 3.32
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 26-SEP-1988    ArticleIdent: Q35299

 The following is a listing of the directories for each of the
 Microsoft Pascal Version 3.32 Compiler distribution disks (5.25-inch disks).
 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; 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.

 The following is a listing of directories for Pascal Version 3.32
 distribution disks:

 Disk 1 of 2  --

 Volume in drive A is DISK 1
 Directory of  A:\

 PAS1     EXE    98284  11-20-86   4:39p
 PAS2     EXE   114760  11-20-86   4:35p
 PAS3     EXE    28310  11-20-86   4:36p
 LINK     EXE    48471   6-12-86   3:04p
 README   DOC    26972  11-20-86   5:34p
 CODEVIEW DOC     2375  11-20-86   5:26p
 LIB      EXE    29359   6-25-86   5:38p
         7 File(s)     10240 bytes free

 :::::::::::::::::::::::::::::::::::::::

 Disk 2 of 2  --

  Volume in drive A is DISK 2
  Directory of  A:\

 MATH     LIB    40960  10-31-86   6:58p
 ALTMATH  LIB    39936  10-31-86   6:59p
 DECMATH  LIB    28160  10-31-86   6:59p
 8087     LIB    29696  10-31-86   6:59p
 PASEXEC  INC     4406  11-03-86   7:03p
 DEMOEXEC PAS     1211  11-04-86  12:31p
 FINU             5482   1-25-85   4:22p
 NULE6    OBJ      586   1-25-85   4:23p
 FINK             3472   1-25-85   4:22p
 FINKXU           4361   1-25-85   4:22p
 LVARSTCK OBJ      442   3-04-85   5:54p
 SORT     PAS     2097  12-10-83  12:11p
 PRIMES   PAS      770  12-10-83  12:11p
 EXEPACK  EXE    11684   3-29-86   8:22a
 EXEMOD   EXE    11034  10-01-85   3:29p
 EMOEM    ASM    11485   9-02-85  12:24p
 CEXEC    LIB    13824  10-29-86   3:09a
 87       EXE     4680   9-16-86   4:00p
 87       DOC      921  11-04-86  12:46p
 PASCAL   LIB    93696  11-19-86   7:17p
        20 File(s)     44032 bytes free


 189. Directory Listing for Pascal 4.00 Distribution Disks

 Product Version(s): 4.00   | 4.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified: 26-SEP-1988    ArticleIdent: Q35300

 Below is a listing of the directories for each of the Microsoft Pascal
 Version 4.00 Compiler distribution disks (5.25-inch disks). 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 is a listing of directories of the Pascal Version 4.00
 distribution disks:

 (Disk 1 of 9)  -  Setup and Compiler

  Volume in drive A is SETUP
  Directory of  A:\

 README   DOC    48065   4-29-88   9:30a
 PACKING  LST     6520   4-27-88  10:31a
 SETUP    EXE    81181   4-22-88   2:27p
 87       EXE     8798   7-23-87   1:34p
 BIND     EXE    36946  10-26-87   4:01p
 ECH      EXE    19351  11-16-87  10:22a
 EXP      EXE    32220  11-17-87   3:38p
 ERROUT   EXE    10729  11-09-87   4:42p
 EXEHDR   EXE    29942   1-14-88   8:44p
 EXEMOD   EXE    12336  11-09-87   4:42p
 EXEPACK  EXE    14803   8-20-87   4:02p
 IMPLIB   EXE    30166   1-29-88  10:23a
 SETENV   EXE    10870  11-09-87   4:43p
        13 File(s)     13312 bytes free

 :::::::::::::::::::::::::::::::::::::::

 (Disk 2 of 9)  -  Utilities

  Volume in drive A is UTILITIES
  Directory of  A:\

 PAS1     EXE   139623   4-21-88  10:05p
 PAS2     EXE   131199   4-21-88  10:05p
 PAS3     EXE    40401   4-21-88  10:06p
 MAKE     EXE    38613   1-29-88  10:26a
         4 File(s)     10240 bytes free

 :::::::::::::::::::::::::::::::::::::::

 (Disk 3 of 9)  -  Examples

  Volume in drive A is EXAMPLES
  Directory of  A:\

 LINK     EXE   117001   2-23-88   5:07p
 PL       EXE    31861   3-25-88  10:29a
 RM       EXE    24884  11-16-87  10:20a
 FINK             3472   1-25-85   4:22p
 FINKXU           4331   8-27-87   4:09p
 FINU             5482   1-25-85   4:22p
 CLOCK    INT      308   5-15-87   4:15p
 INTRP    INT      225   5-15-87   4:15p
 PASEXEC  INC     4450   5-14-87   6:00p
 PORT     INT      129   5-15-87   4:15p
 BSE      INT     1062   1-15-88   8:46p
 BSEERR   INT    18185   1-15-88   8:46p
 BSESUB   INT    20490   2-05-88   6:15p
 OS2      INT      716   1-15-88   8:46p
 OS2DEF   INT     1835   1-22-88   9:31a
 BSEDOS   INT    39921   2-12-88   6:43p
 DEMOEXEC PAS     1211  10-29-86   2:55a
 PRIMES   PAS      634   3-06-87   2:38p
 SORTDEMO PAS    27342   2-02-88  10:31a
 MAKESORT BAT     1326   2-11-88  10:06a
 MAKESORT CMD     1313   2-19-88   7:52p
 EMOEM    ASM    12125  10-22-87   6:46p
 ENTX6L   ASM    10863  12-16-87   2:46a
 ENTXSTUB ASM      394  10-06-87   7:01p
        24 File(s)     18432 bytes free

 :::::::::::::::::::::::::::::::::::::::

 (Disk 4 of 9)  -  Libraries 1

  Volume in drive A is LIBRARY-1
  Directory of  A:\

 UNDEL    EXE    30046  11-16-87  10:24a
 LVARSTCK OBJ      487   2-09-88   1:28p
 APILMR   OBJ      105  10-15-87   6:01p
 ENTX6L   OBJ     1357   3-09-88  10:54p
 5ENTX6L  OBJ     1320   3-09-88  10:54p
 ENTX6W   OBJ     1339   3-09-88  10:55p
 5ENTX6W  OBJ     1302   3-09-88  10:55p
 API      LIB    81408  12-11-87   1:51p
 DOS30P   LIB    26919   4-21-88   9:31p
 DOS50P   LIB    25443   4-21-88   9:31p
 EMR      LIB    16409   1-14-88   4:33p
 EM       LIB    16921   1-14-88   4:33p
 87R      LIB     4121   1-14-88   4:33p
 87       LIB     4121   1-14-88   4:33p
 CEXEC    LIB    14089   4-21-88   9:12p
 DOSCALLS LIB    29184   1-07-88  11:34a
 PASLIBW  LIB    82441   4-21-88   9:32p
 WIN87EM  LIB     1055  10-03-87   6:17p
 MAKELIB  BAT     3148   3-09-88  10:44p
        19 File(s)      8192 bytes free

 :::::::::::::::::::::::::::::::::::::::

 (Disk 5 of 9)  -  Libraries

  Volume in drive A is LIBRARY-2
  Directory of  A:\

 LIB      EXE    49661   2-09-88  10:53a
 EXEC     EXE     9299  12-29-87  10:25a
 ILINK    EXE    88929   2-03-88  10:30a
 NULF     OBJ      957   1-06-87   3:42p
 NULE6    OBJ      586   1-25-85   4:23p
 PARTIAL  LIB    56763   4-21-88   9:31p
 ALTMATH  LIB    41989   1-14-88   3:55p
 DECMATH  LIB    27969   1-14-88   3:55p
 IEEEMATH LIB    24847   1-14-88   3:54p
 8087     LIB    24849   1-14-88   3:54p
 MAKELIB  BAT     3148   3-09-88  10:44p
 MAKELIB2 BAT     3846   3-09-88  10:48p
        12 File(s)     22528 bytes free

 :::::::::::::::::::::::::::::::::::::::

 (Disk 6 of 9)  -  Microsoft CodeView for MS-DOS

  Volume in drive A is CODEVIEW
  Directory of  A:\

 CV       EXE   263890   3-09-88   1:54a
 CV       HLP    22444   1-12-88   4:57p
 CVPACK   EXE    49400   3-01-88  12:07a
 MOUSE    COM    14551   3-06-88   9:41a
         4 File(s)     10240 bytes free

 :::::::::::::::::::::::::::::::::::::::

 (Disk 7 of 9)  -  Microsoft CodeView for MS OS/2

  Volume in drive A is CODEVIEWOS2
  Directory of  A:\

 CVP      EXE   233249   3-09-88   1:56a
 CVP      HLP    22444   1-12-88   4:57p
         2 File(s)    106496 bytes free

 :::::::::::::::::::::::::::::::::::::::

 (Disk 8 of 9)  -  Microsoft Editor

  Volume in drive A is EDITOR
  Directory of  A:\

 CALLTREE EXE    31233  12-29-87   4:03p
 M        EXE    94821   2-02-88   5:35p
 MEP      EXE    97063   2-02-88   5:36p
 MEGREP   EXE    31915  11-16-87  10:23a
 BRIEF    INI     2094   1-14-88  10:38p
 EPSILON  INI      978   1-14-88  10:42p
 QUICK    INI     1058   1-14-88  10:51p
 WS       DLL     2609  12-15-87   5:14p
 WS       ZXT     2084  12-15-87   5:14p
 EXT      DOC    15877   1-07-88  11:25a
 EXT      H       8730  12-15-87   4:06p
 EXTHDR   OBJ     1893  12-15-87   5:13p
 EXTHDRP  OBJ     2021  12-15-87   5:14p
 SKEL     C       2457  10-23-87   9:29a
 SKEL     DEF      211  12-14-87   3:08p
        15 File(s)     59392 bytes free

 :::::::::::::::::::::::::::::::::::::::

 (Disk 9 of 9)  -  Startup Source Code

  Volume in drive A is STARTUP
  Directory of  A:\

 DOS          <DIR>      4-22-88   2:16p
 OS2          <DIR>      4-22-88   2:16p
 PATCH32      <DIR>      4-22-88   2:16p
 BRKCTL   INC      784   2-09-88  10:08p
 CHKSTK   ASM     2044   2-21-88   6:54p
 CHKSUM   ASM     3524   2-09-88  10:09p
 CMACROS  INC    12066   2-09-88  10:08p
 CRT0FP   ASM     2223   2-09-88  10:09p
 FMSGHDR  ASM     2429   2-09-88  10:09p
 MAKEFILE         4148   2-21-88   6:50p
 MSDOS    H       6849   2-09-88  10:10p
 MSDOS    INC     6181   2-21-88   6:53p
 NULBODY  C         13   2-09-88  10:10p
 README   DOC     3199   1-27-88   4:57p
 REGISTER H        922   2-09-88  10:10p
 SETARGV  ASM      971   2-09-88  10:09p
 STARTUP  BAT     1663   1-27-88   4:57p
 VERSION  INC      503   2-09-88  10:08p
 WILD     C       7182   2-09-88  10:09p
 FILE2    H       1027   2-09-88  10:10p
 _FILE    C       1691   2-09-88  10:09p
        21 File(s)    158720 bytes free

  Volume in drive A is STARTUP
  Directory of  A:\DOS

 .            <DIR>      4-22-88   2:16p
 ..           <DIR>      4-22-88   2:16p
 CRT0     ASM     7612   2-09-88  10:09p
 CRT0DAT  ASM    14175   2-09-88  10:09p
 CRT0MSG  ASM     2840   2-09-88  10:09p
 EXECMSG  ASM     1337   2-09-88  10:09p
 NMSGHDR  ASM     3010   2-24-88   3:37p
 NULBODY  LNK      149   2-21-88   6:51p
 STDALLOC ASM     2825   2-09-88  10:09p
 STDARGV  ASM    13852   2-09-88  10:09p
 STDENVP  ASM     3780   2-21-88   6:54p
        11 File(s)    158720 bytes free

  Volume in drive A is STARTUP
  Directory of  A:\OS2

 .            <DIR>      4-22-88   2:16p
 ..           <DIR>      4-22-88   2:16p
 CRT0     ASM    10312   2-21-88   6:54p
 CRT0DAT  ASM    10496   2-09-88  10:09p
 CRT0MSG  ASM     2891   2-09-88  10:09p
 EXECMSG  ASM     2231   2-17-88   8:49a
 NMSGHDR  ASM     3486   2-09-88  10:10p
 NULBODY  LNK      168   2-21-88   6:51p
 STDALLOC ASM     3245   2-09-88  10:10p
 STDARGV  ASM    13623   2-09-88  10:10p
 STDENVP  ASM     5362   2-21-88   6:54p
        11 File(s)    158720 bytes free

  Volume in drive A is STARTUP
  Directory of  A:\PATCH32

 .            <DIR>      4-22-88   2:16p
 ..           <DIR>      4-22-88   2:16p
 PATCH87  DOC     3937   2-19-88   4:30p
 PATCH87  EXE     4206   1-29-88   2:30p
 SETRHS   EXE      543   6-29-86   4:00a
 RMRHS    EXE      543   6-29-86   4:00a
 STKPAT   BAT       94   6-29-86   4:00a
 STKPAT   SCR       30   6-29-86   4:00a
 PTRACE87 PAT      188   1-06-88  10:57p
 PATCH320 DOC     2169   2-19-88   4:29p
 OS2PATCH EXE     1069   1-19-88   4:29p
 OS2PATCH DOC     1401   2-19-88   4:28p
        12 File(s)    158720 bytes free


 190. Example of File I/O and Writing to Printer in Pascal

 Product Version(s): 3.1x 3.20 3.3x 4.00 | 4.00
 Operating System:   MS-DOS              | OS/2
 Flags: ENDUSER | appnote
 Last Modified: 26-SEP-1988    ArticleIdent: Q35557

 The following is an example of simple file I/O, and writing to the
 printer in Pascal.

 The following is a sample program:

 {Program to demonstrate file and device I/O.

  First, perform console I/O by prompting user for keyboard input
  and sending input to screen.

  Then do same to and from a text file named "test.txt".

  Finally, open the printer and send a user-specified string to it.

  Text files are terminated by an End Of Line marker (a line feed),
  which must be written and read by writeln and readln instead of
  read and write.
 }

 program IO(input,output);
   var filevar : text;
       str     : lstring(80);

 begin
   {perform simple console string I/O}
   writeln;
   writeln('Input string of 80 or fewer characters : ');
   readln(str);
   writeln;
   writeln('String was : ',str);

   {create file "test.txt", and perform string I/O}
   assign(filevar, 'test.txt');  {assign name to file variable}
   rewrite(filevar);             {open new file for writing}
   writeln;
   writeln('Input string to write and read from file :');
   readln(str);
   writeln(filevar, str);   {write string to file}
   reset(filevar);          {reset file pointer to beginning of file}
   readln(filevar, str);    {read string & then display it}
   writeln('String was : ',str);
   close(filevar);          {close file, flushing file buffer, and
                             making filevar reusable}

   {open printer device and write string to it}
   assign(filevar, 'prn');  {"prn" is name of printer}
   rewrite(filevar);
   writeln;
   writeln('Input string to send to printer :');
   readln(str);
   writeln(filevar, str);
   close(filevar);

   writeln;
   writeln('Program completed. Good-bye.')
 end.


 191. Example of Allocating Memory on the far/long Heap in Pascal

 Product Version(s): 3.3x 4.00 | 4.00
 Operating System:   MS-DOS    | OS/2
 Flags: ENDUSER |
 Last Modified: 26-DEC-1990    ArticleIdent: Q35561

 The following is an example of dynamically allocating memory on the
 far (or long) heap in Pascal. This information applies to Microsoft
 Pascal Compiler versions 3.3x and 4.00 for MS-DOS, and version 4.00
 for MS-DOS and MS OS/2.

 The following is a program to show far (or long) heap allocation
 routines:

 {First allocate a maximum size block of 65,516 bytes. Assign values to
  the first bytes by an assignment statement and the fillsc procedure
  and display the memory contents on the screen.

  Allocate 64K byte blocks, then allocate 4K blocks until
  there are no more blocks of memory. Then free the blocks.

  The function allmqq is used to allocate blocks of memory, and
  returns a segment:offset "ads" type pointer. The function fremqq
  is used to free the blocks. An ads type has a ".s" field for the
  segment pointed to, and a ".r" type for the offset. If ".r" = 0,
  there is insufficient memory available for the request.
  If ".r" = 1, memory is corrupted.

  Unlike their counterparts getmqq and dismqq, allmqq and fremqq
  do not display error messages, so error checking is done within
  the program.

  Like the equivalent large-memory model C run-time library function
  malloc(), allmqq will first allocate blocks in the far/long heap
  above the default data segment (or Dgroup) until it is exhausted,
  then it will allocate blocks from the near heap in the default
  data segment.

  The NEW and DISPOSE routines can be used to allocate memory within
  the 64K byte or smaller default data segment too, though these are
  not demonstrated here. NEW and DISPOSE do not allocate memory on
  the far/long heap.

  For more information on far heap allocation, see pages 73-76 of the
  "Microsoft Pascal Compiler User's Guide," and the alphabetical
  listing of routines in the "Microsoft Pascal Compiler Reference
  Manual."
 }

 program AllocHeapMemory(input,output);
   const maxsize = 65516; {max size of far heap allocation block}
   type  bigptr_type   = ads of array [wrd(1)..wrd(maxsize)] of byte;
         smallptr_type = ads of array [1..4096] of byte;
   var   bigptr        : bigptr_type;           {pointer to 64K block}
         smallptr      : smallptr_type;         {pointer to 4K  block}
         {define arrays of pointers}
         arrbigptr     : array [1..50]   of bigptr_type;
         arrsmallptr   : array [1..1000] of smallptr_type;
         retcode       : word;            {return code from fremqq   }
         bigallocs,                       {number of big  allocations}
         smallallocs,                     {number of small allocs    }
         i             : integer;         {index to array of pointers}
         goodsmallptrs,                   {to indicate errors from   }
         goodbigptrs   : boolean;         {  freeing blocks          }

   {far heap allocation and free routines}
   function allmqq(allocsize : word)   : adsmem; extern; {alloc block}
   function fremqq(ptr       : adsmem) : word;   extern; {free  block}

 begin
   writeln;
   writeln('Allocate and free a single block on far/long heap:');
   bigptr := allmqq(sizeof(bigptr^));
   if (bigptr.r = 0) then
     writeln('Far heap allocation failed due to lack of memory.')
   else
     if (bigptr.r = 1) then
       writeln('Far heap allocation failed due to corrupted memory')
     else
       begin
         write('Segment:Offset of pointer to allocated block is ');
         writeln(bigptr.s:5, ':', bigptr.r:-5);
         {free block}
         retcode := fremqq(bigptr);
         if (retcode = 1) then
           writeln('Error freeing far pointer.')
       end;

   writeln;
   writeln('Begin allocation of 65516 byte blocks in far heap.');
   writeln;
   writeln('Display address of blocks allocated:');
   i := 1;
   bigallocs := 0;
   arrbigptr[i] := allmqq(sizeof(arrbigptr[i]^));
   while (arrbigptr[i].r <> 0) do
     begin
       write('Segment:Offset = ');
       writeln(arrbigptr[i].s:5, ':', arrbigptr[i].r:-5);
       bigallocs := bigallocs + 1;
       i := i + 1;
       arrbigptr[i] := allmqq(sizeof(arrbigptr[i]^))
     end;

   writeln;
   writeln('No more large blocks available in far heap.');
   writeln('Allocate 4K blocks -- notice that near heap is used');
   writeln('after far heap is exhausted as shown by pointers to');
   writeln('blocks in lower memory');
   writeln;
   writeln('Display address of blocks allocated:');
   i := 1;
   smallallocs := 0;
   arrsmallptr[i] := allmqq(sizeof(arrsmallptr[i]^));
   while (arrsmallptr[i].r <> 0) do
     begin
       write('Segment:Offset = ', arrsmallptr[i].s:5, ':');
       writeln(arrsmallptr[i].r:-5);
       smallallocs := smallallocs + 1;
       i := i + 1;
       arrsmallptr[i] := allmqq(sizeof(arrsmallptr[i]^))
     end;

   writeln;
   writeln('Far and near heap allocated. Now free blocks:');
   goodbigptrs := true;
   {free large blocks in far/long heap}
   for i := 1 to bigallocs do
     begin
       retcode := fremqq(arrbigptr[i]);
       if (retcode <> 0) then
         begin
           goodbigptrs := false;
           write('Bad pointer segment:offset at ');
           writeln(arrbigptr[i].s:5, ':', arrbigptr[i].r:-5)
         end
     end; {for}
   if (goodbigptrs) then
     writeln('Large blocks freed without error.');

   {free small blocks in far and near heap}
   goodsmallptrs := true;
   for i := 1 to smallallocs do
     begin
       retcode := fremqq(arrsmallptr[i]);
       if (retcode <> 0) then
         begin
           goodsmallptrs := false;
           write('Bad pointer segment:offset at ');
           writeln(arrsmallptr[i].s:5, ':', arrsmallptr[i].r:-5)
         end
     end; {for}
   if (goodsmallptrs) then
     writeln('Small blocks freed without error.');

   writeln;
   writeln('Program completed. Good-bye.')
 end.


 192. Pascal 4.00 TMP Varible Setting Causes "Line invalid" Error

 Product Version(s): 4.00   | 4.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | buglist4.00
 Last Modified: 26-SEP-1988    ArticleIdent: Q35813

 The TMP environment variable set to C:\C\TMP causes the pl driver to
 fail when one or more options other than /c is given.

 The following is an example:

 pl /Zi /Pd foo.pas

 The result is as follows:

 Line invalid: 'junk', start again.
 Source filename [.PAS] :

 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.

 The workaround to this problem is to change the TMP variable setting.


 193. The Standards to which MS Pascal Conforms

 Product Version(s): 4.00   | 4.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified: 18-OCT-1988    ArticleIdent: Q36802

 The ISO standard ISO 7185 for Pascal has two levels, 0 and 1. Level 0
 is identical to the ANSI/IEEE Pascal standard. Pascal Version 4.00
 supports the ANSI/IEEE Pascal standard, so Microsoft also supports ISO
 level 0.

 Note: level 1 of ISO is level 0 plus conformant array parameters.



 194. Pascal Versions 3.3x and Later Support Linker /STACK Switch

 Product Version(s): 3.2x 3.3x 4.00 | 4.00
 Operating System:   MS-DOS         | 4.00
 Flags: ENDUSER | s_link
 Last Modified: 24-OCT-1988    ArticleIdent: Q37207

 Microsoft Pascal, Versions 3.2x, do not support the linker switch
 /STACK for changing the stack size at link time. This option is
 supported in Versions 3.3x and later.

 In Versions 3.2x, a program was set to provide a variable size stack.
 Setting a stack size with the linker switch, and then having that size
 changed by a program, could cause unpredictable results. For this
 reason, you should not use the /STACK switch. This information is
 documented in the note at the bottom of Page 66 in the "Microsoft
 Pascal User's Guide" for Versions 3.2x and later.

 In Versions 3.3x and later, the stack size is fixed by the compiler.
 Therefore, changing stack size when linking is safe. The documentation
 note on Page 66 in the user's guide for Versions 3.3x and 4.00 is
 outdated. You will find more information on the /STACK linker switch
 in the README.DOC file that comes with Versions 3.3x and on Page 270
 in the "Microsoft CodeView and Utilities" manual that comes with
 Version 4.00.


 195. Error R6009 Not Enough Space for Environment in Pascal

 Product Version(s): 4.00
 Operating System:   MS-DOS
 Flags: ENDUSER | SR# S881020-4
 Last Modified: 12-FEB-1990    ArticleIdent: Q37217

 Question:

 I receive the following error at run time (or as I walk through the
 startup code in CodeView):

    R6009  not enough space for environment

 How can I remove this error?

 Response:

 The startup code loads the environment strings into the near heap.
 This behavior may cause the program to run out of heap space if you
 have a large amount of data or if your stack is large. Essentially,
 you are running out of space in DGROUP. To correct this problem,
 insert the following two procedures into the same module that defines
 the main program:

    procedure _setargv [public, c];
    begin
    end;

    procedure _setenvp [public, c];
    begin
    end;

 You will need to link with the /NOE option so that you do not get
 multiple definitions of these two routines.

 Note: This is basically a Pascal translation of the procedure
 described on Page 131 of the "Microsoft C Optimizing Compiler User's
 Guide" for Versions 5.00 and 5.10.


 196. Determining Available Memory

 Product Version(s): 4.00   | 4.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | docerr
 Last Modified:  8-NOV-1988    ArticleIdent: Q37610

 Page Update-45 (section 5.3) of the "Microsoft Pascal Compiler for MS
 OS/2 and MS-DOS Operating System Version 4.0 Update" manual
 incorrectly states the following:

    FREECT(0) * 2 - MEMAVL returns the number of free bytes in the
    heap itself.

 This should read as follows:

    FREECT(0) * 2 returns the number of free bytes in the heap
    itself.


 197. Using packed Type Has No Effect on Variable's Storage.

 Product Version(s): 4.00   | 4.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | sizeof
 Last Modified: 23-NOV-1988    ArticleIdent: Q38165

 In Microsoft Pascal, packed type will not affect storage of the
 variables with the packed type. This is specified in the "Microsoft
 Pascal Compiler User's Guide." (See section 9.2 Internal Representation
 of Data Type.) Therefore, the "sizeof" function will return unpacked
 size. The following is an example:

 Type
     packed_type = packed array [1..9] of byte ;
     unpacked_type = array [1..9] of byte ;
 var
     var1 : packed_type ;
     var2 : unpacked_type ;

 'var1' and 'var2' both occupy 10 bytes in memory.

 In Microsoft, storage of variables is word aligned.

 A component of a packed structure cannot be passed as a reference
 parameter unless the structure is of a string type. Therefore,
 following usage of sizeof function is illegal.

 The following is an example:

 var
     var_arr: packed array [1..10] of unpacked_type ;
 begin
     sizeof (var1[1]) ;
 end.


 198. Pascal Version 4.00 Can't Watch lstring in CodeView

 Product Version(s): 4.00    | 4.00
 Operating System:   MS-DOS  | OS/2
 Flags: ENDUSER | s_CodeView
 Last Modified: 23-NOV-1988    ArticleIdent: Q38300

 The Microsoft CodeView debugger Version 2.20 does not allow watching a
 lstring variable directly. The command "w ? lstr_var" responds with a
 "?CANNOT DISPLAY" message. The workaround is to use the "wa a l10".
 This is the watch ASCII expression at address lstr_var with a length
 of 10.

 The "w ? lstr_var" instruction was not implemented in CodeView Version
 2.20.


 199. CodeView Does Not Watch Non-Zero Based Arrays Correctly

 Product Version(s): 4.00   | 4.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | S_Codeview
 Last Modified:  2-MAR-1989    ArticleIdent: Q40382

 Problem:

 I have written a program that defines an array with a non-zero base.
 The following is an example:

    data : array[2..5] of integer;

 In CodeView, I do not see the correct values when I set a watch on
 elements of this array.

 Response:

 This is a problem with the symbolic information generated by the Pascal
 compiler. Given the information passed to it, CodeView determines that
 all Pascal arrays have a base of zero -- even when they don't.

 A workaround to this problem is to adjust for this miscalculation by
 offsetting the index of any watched array so that its effective base
 is zero. For example, given the array defined above, you would
 actually set a watch on data[1] to watch data[3]. To watch data[x],
 set a watch on data[x-2].


 200. "Unresolved Externals" from DOSCALLS.LIB under OS/2.

 Product Version(s): 4.00
 Operating System:   OS/2
 Flags: ENDUSER |
 Last Modified: 23-NOV-1988    ArticleIdent: Q38357

 When compiling and linking in protected mode under OS/2 and using any
 systems calls, it is necessary to use the /Lp switch to bring in the
 library DOSCALLS.LIB. Attempting to use routines from DOSCALLS.LIB
 without using the /Lp switch results in the error "L2029: unresolved
 externals." This error occurs because the linker only brings in the
 standard Pascal library when you do not specify the /Lp switch. An
 alternate solution is to link separately, and specify both
 LIBPASEP.LIB and DOSCALLS.LIB on the link line.

 For example, to compile and link the file "EXAMPLE.PAS" for OS/2
 protected mode, use one of the following commands:

    PL /Lp EXAMPLE.PAS

    PL /c EXAMPLES.PAS
    LINK EXAMPLES.OBJ,,,LIBPASEP.LIB DOSCALLS.LIB


 201. Enumerated Types Input/Output as String Is Not Implemented

 Product Version(s): 4.00   | 4.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified: 14-FEB-1991    ArticleIdent: Q38393

 The sample program below uses the write format P::1 described on page
 284 of the "Microsoft Pascal Reference Manual" to output an enumerated
 type variable as a string. The program generates the following
 run-time error:

    ? Error: Data format error in file USER
      Error Code 1125

 The reading and writing of enumerated types is not possible in
 Microsoft Pascal. This limitation is explained in the "Microsoft
 Pascal User's Guide," Appendix B.3, "Unimplemented Features."

 The following is a sample program:

 (* Sample program *)
 program enumtype (input, output) ;
 type
     enumtype = (abc, xyz) ;
 var
     evar : enumtype ;

 begin
     evar := abc ;
     writeln(evar::1) ;  (* attempt to output 'abc' *)


 202. Error 133 Type Size Overflow with /Zi or /Z.

 Product Version(s): 4.00
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 28-NOV-1988    ArticleIdent: Q38474

 Page 231 of the "Microsoft Pascal User's Guide" defines the "133 Type
 Size Overflow" error as follows:

    "The data type declared implies a structure bigger than the maximum
    of 65534 bytes"

 Pascal does not support data structures larger than 64K. However, this
 error sometimes occurs only when a program is compiled with the
 CodeView switches /Zi (for the PL driver) or /Z (for the PAS1 driver).
 This behavior occurs when a reference is made to a data structure that
 exceeds 64K in size, but the structure is never initialized and no
 memory allocation is made in the code.

 For example, the following line of code compiles with no errors if the
 CodeView switch is not used; however, it generates "133 Type Size
 Overflow" if the /Z or /Zi switch is used:

    XPTR:   ADS OF ARRAY [0..37500] OF REAL;

 This error occurs even if no allocation or initialization of the array
 occurs. If the structure itself is declared as follows, or if an
 attempt is made in the program to allocate memory for the array, the
 error occurs at compile time, regardless of the combination of
 command-line switches used:

    X : ARRAY [0..37500] OF REAL;

 Apparently, using the /Zi or /Z switch causes the compiler to check
 the referenced data type more closely, and detect the error before the
 allocation is actually made.


 203. Printing Formfeeds in Pascal

 Product Version(s): 4.00   | 4.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified:  2-MAR-1989    ArticleIdent: Q40078

 Problem:

 I'm sending output to my printer in Pascal. When my application is
 finished, I send a form feed to reset the page, but when I close the
 printer file, I get an extra line feed. The following code produces
 the problem:

     program printage(output);

     var filevar : text;

     begin

         assign(filevar, 'prn');
         rewrite(filevar);

         writeln(filevar, 'This is the first line!');
         write(filevar, chr(12));

         close(filevar)

     end.

 Response:

 By default, Pascal's file system uses records ending with LF. When
 the printer file from the Pascal source above is closed, a linefeed
 is appended to the file automatically to terminate the record that has
 been started, i.e., the single formfeed character.

 A simple solution to this situation is to not close the printer file.
 Normal files are closed by the exit code, but device files are handled
 differently, and will not have any unfinished records terminated.


 204. Printf() Example Is Wrong in Mixed-Language Guide

 Product Version(s): 4.00   | 4.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | docerr s_c h_fortran h_masm
 Last Modified:  7-MAR-1990    ArticleIdent: Q58178

 The sample program TEST on Page 135 of the "Microsoft Mixed-Language
 Programming Guide" is incorrect, not only in syntax but also in its
 functionality.

 The program is presented to demonstrate the use of the VARYING
 attribute, which allows you to call functions from the C run-time
 library with a different number of arguments each time. This is
 demonstrated in this case by calling the C run-time function printf()
 directly from Pascal.

 However, the TYPE declaration and the three assignment statements in
 the main program body are syntactically incorrect. Replace the colon
 (:) in the "TYPE stype30 : string(30)" statement with an equal sign
 (=), and replace each of the equal signs in the assignment statements
 with Pascal assignment operators (:=).

 After correcting the syntax errors, the program still will not work.
 When linked with the large model C run-time library LLIBCE.LIB, it
 will return an incomplete string under DOS and will cause a
 protection violation under OS/2.

 For this program to work correctly, the argument(s) passed to printf()
 must be ADS pointers of type ADSMEM. ADSMEM is a predefined address
 type, which is equivalent to a far pointer type in C. When the ADS
 pointer type is used, the full segment:offset addresses of the strings
 are passed. The following is the corrected version of the program:

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

 program Test(input,output);
 type
         stype30 = string(30);

 var
         str1 : string(30);
         str2 : string(10);
         n    : integer;

 procedure printf (s1 : ADSMEM) [C, VARYING]; extern;
 begin
         str1 :='This is %s string, number %d.' * chr(0);
         str2 :='formatted' * chr(0);
         n := 1;
         printf(ADS str1, ADS str2, n);
 end.

 This code runs correctly under DOS and OS/2. The output is as follows:

    This is formatted string, number 1.


 205. Using a function to set the offset of a ptr is unreliable

 Product Version(s): 4.00   | 4.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | pointers offset
 Last Modified:  2-MAR-1989    ArticleIdent: Q40483

 The use of a function to change the offset of a pointer does not
 always work reliably. If used within a decision structure, such a
 function does not return the expected value. However, if assigned to a
 pointer, and then used within a similar decision structure, the
 function returns the proper offset. Although the function returns the
 expected offset when assigned to a pointer, it does not actually alter
 the offset of the pointer within the function.

 The following code sample exhibits this performance:

 PROGRAM pointertest(output);

 TYPE
   ptrtyp = ADS OF WORD;

 FUNCTION get_ptr : ptrtyp;
 {  This function will return an offset of 1, however get_ptr.R will
    never actually be set to 1 }
 Begin
   get_ptr.R := 1;
 End;

 VAR
   ptr : ptrtyp;

 BEGIN
   if get_ptr.R = 0 then     ! Because get_ptr never actually sets
                             ! the offset to 1, this comparison fails;
     writeln ('Returned 0')
   else
     writeln ('It worked!');
   writeln;
   ptr := get_ptr;           ! however, because get_ptr returns a
                             ! proper value, the following decision
   if ptr.R = 0 then         ! structure fuctions as expected.
     writeln ('Improper operation')
   else
     writeln ('This should work properly.');
 END.


 206. Example on Page 16 of Pascal Utilities Manual Is Incorrect

 Product Version(s): 4.00   | 4.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | docerr
 Last Modified:  2-MAR-1989    ArticleIdent: Q41221

 The example on Page 16 of the "Microsoft Pascal 4.0 Compiler Microsoft
 CodeView and Utilities and Microsoft Editor" manual is incorrect. The
 command line: PL /Zi /c TEST does not produce an object file because
 no .PAS extension was given. To work around the problem, add the .PAS
 extension.


 207. Include Files Not Handled as Documentation Describes

 Product Version(s): 4.00   | 4.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | docerr
 Last Modified: 28-MAR-1989    ArticleIdent: Q42238

 Page Update-34 of the "Microsoft Pascal 4.0 Compiler User's Guide" states
 the following:

    When you use the $INCLUDE metacommand, the compiler looks for the
    specified file in this order:

    1. The specified directory, if you give a complete path name

    2. The current working directory

    3. Each directory listed in the INCLUDE environment variable

    For example, suppose that your source file contains the following
    metacommand:

        $INCLUDE \PAS\IAS

     In addition, the INCLUDE environment variable is set as below:

        C:\INC;C:\PAS\INC

     In this case, the compiler attempts to find the file IAS by
     searching directories in this order:

     1. The \PAS option on the current drive

     2. The current working directory

     3. The \INC option on drive C

     4. The \PAS\INC option on drive C

 There are a couple of problems with these statements.

 First, the proper syntax for an INCLUDE metacommand is as follows:

    { $INCLUDE: '\PAS\IAS' }

 Second, the specified directories is NOT searched. Because \PAS\INC
 fully qualifies the include file pathname, it only is found if INC is
 in the PAS directory immediately off the root. In the four cases
 above, the filespec actually searched for will be as follows:

 1. \PAS\IAS                     (This is correct)

 2. \PAS\IAS                     (Not starting at CWD)

 3. \INC\\PAS\IAS                (Violates DOS pathname spec)

 4. \PAS\INC\\PAS\IAS            (Violates DOS pathname spec)

 The directories would be properly searched if the include file IAS was
 not fully qualified.


 208. SORTDEMO Needs to Be Bound in Order to Run in DOS

 Product Version(s): 4.00   | 4.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified:  6-APR-1989    ArticleIdent: Q42944

 Question:

 Why do I get the following message from the Pascal compiler while
 trying to compile SORTDEMO.PAS in DOS?

    File Access Error In os2.int; code: 1140; Status: 110
    Compiler cannot continue

 Response:

 In order to be able to run SORTDEMO.PAS in DOS, you must BIND it. You
 will not have the necessary files to compile and BIND SORTDEMO if you
 set up for DOS only.

 OS2.INT is the include file that SORTDEMO.PAS uses. If you have not
 set up the Pascal compiler for OS/2, the OS2.INT file will not be
 copied to the hard disk during setup. Therefore, the compiler will not
 be able to open this file and will generate the error mentioned above.


 209. fremqq Fails to Free Memory Block

 Product Version(s): 4.00   | 4.00
 Operating System:   MS-DOS | OS-2
 Flags: ENDUSER |
 Last Modified: 28-MAR-1989    ArticleIdent: Q42765

 The following PASCAL program will not produce correct results under
 DOS, and causes a GP fault in OS/2. The program allocates a block of
 memory using the allmqq function, and then frees it using fremqq.

 Under DOS, the memory is never really freed, even though the fremqq
 returns a 0, indicating the free was successful. In OS/2 protect mode,
 a GP fault is generated immediately upon execution of the program.

 To prevent the problem, change the following statement:

     IF (ads0 <> ads out_im[1])
        THEN ww := fremqq (ads0);

 to the following:

     IF (ads0 <> ads out_im[1])
        THEN BEGIN
                 IF TRUE THEN ;
                 ww := fremqq (ads0);
             END;

 Also, a "WRITELN(' ');" statement will work in place of the dummy IF
 statement, as well. A "WRITE;" will NOT work. Also, installing the
 PASCAL 4.00 lstring patch has no effect.

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

 The complete program is as follows:

 PROGRAM memtest (INPUT, OUTPUT);

 FUNCTION allmqq (wants : WORD) : adsmem ; EXTERNAL;
 FUNCTION fremqq (block : adsmem) : WORD ; EXTERNAL;

 VAR [PUBLIC]
     out_im : LSTRING (128);

 PROCEDURE insert_bchrec2 (CONST bytes : INTEGER4) [PUBLIC];

 VAR
    ads0     : adsmem;
    ww       : WORD;

 VAR [STATIC]
    buffersize : WORD;
    VALUE buffersize := 65408;

 BEGIN
     ads0.r := 0;

     WHILE ((buffersize >=128) AND (ads0.r <= 1)) DO
         BEGIN
             ads0 := allmqq(buffersize);
             IF (ads0.r <= 1)
                THEN buffersize := buffersize - 128;
         END;

     IF (ads0 <> ads out_im[1])
         THEN ww := fremqq (ads0);

     WRITELN (buffersize:1, ',',ads0.s:1,',',ads0.r:1,',',ww:1);

 END;

 BEGIN
     FOR VAR ii := 1 TO 50 DO
         BEGIN
             WRITE (ii:3,': ');
             insert_bchrec2(0);
         END
 END.



 210. Prsrqq() and Prdrqq() prototypes not documented correctly

 Product Version(s): 4.00   | 4.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | buglist4.00
 Last Modified:  6-APR-1989    ArticleIdent: Q43044

 Prsrqq() and prdrqq(), as documented on Page 249 of the Version 4.00
 "Microsoft Pascal Compiler Reference Manual," should return the first
 argument to the power of the second argument. When compiled, linked,
 and run, the code below generates a general protection fault in OS/2
 and, in DOS, generates the following error message:

 ? Error : negative REAL to REAL power
   Error Code 2133

 To correct the problem you must change the function prototype
 from:

 function prsrqq(a,b:REAL4):REAL4;EXTERN;

 to:

 function prsrqq(consts a,b:REAL4):REAL4;EXTERN;



 211. Pascal: Bad Code Produced by Union of Sets

 Product Version(s): 4.00   | 4.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | buglist4.00
 Last Modified:  3-MAY-1989    ArticleIdent: Q43509

 The Microsoft Pascal Version 4.00 Compiler will generate incorrect
 code for the line containing the union and assignment in the program
 fragment below. The problem will arise only if the sets that are
 unioned contain less than 16 elements and the set receiving the union
 has greater than 16 elements.

     TYPE
         SSet = SET OF 1..8;     (* Must have fewer than 16 elements. *)
         LSet = SET OF 1..16;    (* Must have 16 or more elements.    *)

     VAR
         Set1  : SSet;
         Set2  : SSet;
         Union : LSet;

     BEGIN
         Set1 := [1..3];
         Set2 := [5..7];

         Union := Set1 + Set2;   (* Trouble right here! *)
     END.

 The union in this example is done properly in a single register, but
 its assignment to a variable requiring more than a word is incorrect.
 Under DOS, this will create an inaccurate assignment. Under OS/2, the
 assignment also will be inaccurate and may cause a GP fault.

 A pair of temporary variables that are the same size as the variable
 receiving the union can be used to work around the problem. First,
 assign the two smaller sets to the temporary variables, then use the
 temporary variables in the union.

 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.


 212. Setup Fails When Installing Libraries for Windows Programming

 Product Version(s): 4.00
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist4.00
 Last Modified:  3-MAY-1989    ArticleIdent: Q43973

 If the Pascal 4.00 Setup program is invoked with the /L switch to
 install libraries, and you select "Remove stack segment for Windows
 compatibility", Setup will fail. Setup will ask for the Libraries 1
 disk, and upon copying the six necessary files, it will ask again for
 the same disk. Whether you remove the disk, or try other disks, Setup
 continues to ask for the Libraries 1 disk.

 The workaround is to install the libraries without Windows
 compatibility, and make the changes manually. After building the
 library, copy the file ENTX6W.OBJ from the disk marked "Libraries 1"
 into your LIB directory. Change to your LIB directory, and type "LIB
 LIBPASE.LIB". The LIB utility will start and prompt you with the
 following:

    Operations:

 Type "-ENT6L.OBJ+ENTX6W" at this prompt, and press ENTER. Press ENTER
 twice more after this. LIB will convert your library for use with
 Windows programming.

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


 213. Pascal Runs Out of Memory Compiling a Unit

 Product Version(s): 4.00  | 4.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | SR# G890725-23266 buglist4.00
 Last Modified: 26-SEP-1989    ArticleIdent: Q47743

 When compiling the following Pascal unit with the command line

    pl /c /Zi newbits.pas

 the error "Error:  Compiler Out Of Memory" occurs.

 To work around the problem, use one of the following command lines:

    pl /c newbits.pas
    pl /c /Zd newbits.pas

 Including the /Zd option gives line number information that will help
 make debugging in CodeView a little easier.

 The following is the source code for the unit that demonstrates the
 problem:

 *** FILE NEWBITS.PAS ***

 {$include: 'newbits.INT'}
 {$message: 'newbits.PAS'}

 implementation of newbits;

 {$message: '1'}

 var MACHT2_TABEL: array [bit_NR] of Byte;

 {$message: '2'}

 function MACHT2;

 {$message: '3'}

 begin
 {$message: '4'}
   MACHT2:=MACHT2_TABEL[exponent];
 {$MESSAGE: '5'}
 end; {MACHT2}

 {$MESSAGE: '6'}

 procedure SET_BIT {var B:byte; BN:BIT_NR; STATUS:SWITCH};

 begin if not (status = bit_status(b,bn)) then
       begin case status of
              off: B:= B and not macht2_tabel[BN];
              on : B:= B or macht2_tabel[bn]
             end
       end
 end; {setbit}

 function BIT_STATUS {b:byte; BN:BIT_NR):switch};

 begin if (b and macht2_tabel[bn]) = 0 then bit_status := off
                                       else BIT_STATUS := on
 end; {bit_status}

 {$message: '7'}

 {$message: '8'}
 begin {newbits}
       macht2_tabel[0] :=    1;
       macht2_tabel[1] :=    2;
       macht2_tabel[2] :=    4;
       macht2_tabel[3] :=    8;
       macht2_tabel[4] :=   16;
       macht2_tabel[5] :=   32;
       macht2_tabel[6] :=   64;
       macht2_tabel[7] :=  128;

       Nil_adr.R:= 16#0000;

       NIL_ads.S:= 16#0000;
       NIL_ADS.S:= 16#ffff
 end. {newbits}

 *** FILE NEWBITS.INT ***

 {$message: 'newbits.int'}

 interface;

 unit newbits(MAX_BIT_NR,
               SWITCH, OFF, ON,
               BIT_NR,
               SEG_ADDRESS, REL_ADDRESS,
               NIL_ADR, NIL_ADS,
               MACHT2,
               SET_BIT, BIT_STATUS);

 const MAX_BIT_NR = 7;

 type SWITCH = (OFF,ON);

      BIT_NR = 0..MAX_BIT_NR;

      SEG_ADDRESS = ADS OF SEG_ADDRESS;
      REL_ADDRESS = ADS OF REL_ADDRESS;

 var NIL_ADR: REL_ADDRESS;
     NIL_ADS: SEG_ADDRESS;

 function macht2(exponent:BIT_NR):BYTE ;

 procedure SET_BIT(VAR B:BYTE; BN:BIT_NR; STATUS:SWITCH);

 FUNCTION BIT_STATUS(B:BYTE; BN:BIT_NR):SWITCH;

 BEGIN {newbits}
 END; {newbits}


 214. Add Path to Data Filename for Pascal Debugging with CVP2.2

 Product Version(s): 4.00
 Operating System:   OS/2
 Flags: ENDUSER | S_CodeView
 Last Modified: 19-MAY-1989    ArticleIdent: Q44032

 The version of CodeView Protect (CVP) mode that comes with Pascal 4.00
 (i.e., CVP 2.20) does not know where the current working directory is
 located as a result of using the DosStartSession API from OS/2 Version
 1.00, which did not provide this information. With OS/2 Version 1.10's
 DosStartSession, the path of the current working directory would be
 known, but CVP Version 2.20 does not make use of it. Later versions of
 CVP provided with the OS/2 Software Development Kit, such as CVP
 Version 2.30 from OS/2 SDK Version 1.06, do not support Pascal Version
 4.00.

 If you have access to a second monitor the problem goes away with
 the /2 option.

 The following example allows the current working directory, or any
 other path on the current drive, to be defined with the compiler
 option /Ddatafilename=<path>, where <path> is the path to the data
 file to be opened.

 Note: A colon cannot be used in the defined constant for <path>,
 although another symbol could be used and replaced in the {$ifdecl}
 block within the program.

 This program allows the data file's path to be coded into the .EXE so
 that it may be found when debugging the program with CVP 2.20.

 {   Program to prepend path to data filename using compile line
     defined constant "datafilepath", using /Ddatafilepath=\path...
     (Note that path cannot include a colon for a drive letter.)

     This program helps overcome a limitation of CVP 2.20 for Pascal 4.00
     under either OS/2 1.00 or 1.10 of not knowing where the current
     working directory is located, especially if the current directory
     contains the data file in question. An alternative would be to
     hard code the path in the data filename, or debug with all files
     in the root directory of the boot drive.
 }

 program FilePathName(input,output);
 var filevar  : text;          {data text file variable}
     filename,                 {optionally fully qualified file name}
     data     : lstring(80);   {for data to read from file}

 begin
     filename := 'foo';

     {$ifdecl datafilepath $then}
         insert ('\', filename, 1); {insert path in front of file name}
         insert (datafilepath, filename, 1);
     {$end}

     writeln('filename = ',filename);

     {assign file name to file variable, open, read from & close file}
     assign(filevar,filename);
     reset(filevar);
     readln(filevar,data);
     writeln('read file, data = ',data);
     close(filevar);
 end.


 215. Different ADR Types and Different ADS Types Not Compatible

 Product Version(s): 4.00   | 4.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | docerr
 Last Modified: 25-MAY-1989    ArticleIdent: Q44561

 Pascal is ordinarily a strongly typed language, but for ADR or ADS
 address types, Pascal assures only that they are both ADR or both ADS.
 However, Page 108 of the "Microsoft Pascal Reference Manual" for the
 Microsoft Pascal Compiler Version 4.00 is incorrect when stating the
 following:

    ...If P1 is type ADR OF STRING(200) and P2 is any ADR OF type, the
    assignment P1^:=P2^ generates fast code with no range checking.
    Although this capability is not safe, operating systems and other
    software sometimes require it.

 This statement is not correct. Address types can be assigned to each
 other regardless of the data type they point to as long as they are
 both ADR or ADS address types; however, the data they refer to with
 the caret (^) may not be freely assigned to a different type.

 For the address variables P1 and P2 above, assigning one address type
 to another as in the following statement would be correct:

    P1 := P2;  (* ADR := ADR is correct *)

 As with other incompatible data-type assignments in Pascal, a
 data-type conversion function must be used before the assignment is
 made. For the data types referred to by P1 and P2, a correct
 assignment would be as follows:

    P1^[1] := chr(P2^);

 P1^[1] is a single char element of the string referred to by P1, and
 the Pascal chr function converts the data type referred to by P2 to
 the char type that is compatible with a string element.

 The following program demonstrates the ADS OF type incompatibility and
 the associated error message (also produced for ADR OF types):

  program main(input,output);
  var
     p1 : ads of string(200);
     p2 : ads of word;
  begin
     p1^ := p2^;
  end.

 Microsoft (R) Pascal Compiler
 Version 4.00
 (C) Copyright Microsoft Corp 1987-1988. All rights reserved.
     11      9       p1^ := p2^;
             9   -------------^201 Types Not Assignment Compatible
  Pass One     1 Errors Detected.


 216. Program Fails to Receive First Character of Arguments

 Product Version(s): 4.00
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 26-SEP-1989    ArticleIdent: Q47817

 When passing command-line arguments into a Pascal program, the first
 character of the first argument is lost if a space is not used as the
 delimiter. Pascal has built-in routines for reading and parsing
 command line arguments. These routines ignore the first character of
 the argument tail (usually the space delimiter).

 This problem appears to be an oversight of the Pascal start-up code.
 The start-up code parses the argument tail with the assumption that
 the first character is always a space. This works in most cases
 because options are usually separated from the program name with a
 space character. However, to pass arguments into a program without
 using the space delimiter. The "/" delimiter is an example that
 exhibits the problem.

 Another way this problem can occur is by spawning or execing the
 Pascal program from within another application. Arguments that are
 passed with spawn/exec are specified in an argument list. This
 argument list does not normally have a space as the first character.
 The arguments begin without any delimiter, and therefore, Pascal loses
 the first character of the first argument.

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


 217. Additional Explanations of File System Errors 1030 to 1048

 Product Version(s): 3.30 3.31 3.32 4.00
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 18-SEP-1989    ArticleIdent: Q45181

 The following are additional potential or actual explanations for the
 list of file-related run-time errors in Appendix F.4.1, Pages 259-60,
 of the Version 4.00 "Microsoft Pascal Compiler for the MS-DOS
 Operating System User's Guide":

    Error                 Potential or Actual Cause
    -----                 -------------------------

    1030 File system      Misc., see paragraphs below
    1031 Operation        Current user is not owner
    1032 File not found   No such file or directory
    1033 File not found   No such process
    1034 File system      Interrupted system call
    1035 Protected file   Input/Output error
    1036 File system      No such device
    1037 File system      Argument/assignment too long
    1038 File system      Executable file format error
    1039 File system      Bad file number
    1040 File system      No child process
    1041 Data format      No more processes
    1042 File system      Not enough space
    1043 Data format      Permission denied
    1044 File system      Bad address
    1045 Unknown device   Block device required
    1046 File system      Device busy
    1047 File system      File exists
    1048 File system      Cross-device link

 Note: The above explanations may not be completely accurate for every
 occurrence of their associated error, but they are usually correct.

 Run-time error 1030 can occur for a variety of reasons. It is a
 nonspecific file-handling error that does not fit exactly with any
 one of above categories each time it occurs. However, it does occur
 for one or more of the reasons listed above, or because of not having
 enough file handles in DOS.

 The number of file handles can be increased from the default of 8 to
 20 or more, for many implementations of DOS Versions 3.3x and 4.x,
 with the "FILES=" statement followed by a specified number of file
 handles in the root directory file CONFIG.SYS.


 218. Accessing PSP and Command-Line Arguments in Pascal

 Product Version(s): 3.30 3.31 3.32 4.00
 Operating System:   MS-DOS
 Flags: ENDUSER | docerr
 Last Modified:  7-JUN-1989    ArticleIdent: Q45197

 The Pascal public variable "cesxqq" provides the Program Segment
 Prefix (PSP) of the application and is equivalent to the Microsoft C
 variable "_psp". The Version 4.00 "Microsoft Pascal Compiler for the
 MS-DOS Operating System User's Guide" documents "cesxqq" on Page 163.

 Please note that the information regarding "cesxqq" on Page 164 of the
 above manual is entirely correct. Its use of the variable "LOMADS"
 gives only an approximate value for the beginning of the available far
 (or long) heap. Its use of the variable "HIMADS" appears incorrect due
 to the light print of the caret "^" following "MSDATA" in the
 statement that should appear as in the following:

    HIMADS.S := MSDATA^ ;

 The following is a program demonstrating the use of "cesxqq":

 {   This program uses Pascal's public variable "cesxqq" to find
     the segment containing its Program Segment Prefix under DOS.
     Cesxqq is equivalent to the _psp variable in Microsoft C.

     Due to Pascal's data-type checking, two pointers to
     different data types are used, even though the pointers will
     all point to the PSP's segment.

     PSP offset 128 contains a copy of the program's command
     line arguments. Note: This will be blank unless command line
     arguments are given when the program is invoked.

     PSP offset 2 contains the last segment allocated from DOS
     for this program, which is the top of the near heap.

     For additional information on the PSP, please consult a DOS
     programmer's reference.
 }

 Program GetPointerToPSPsSegment(input,output);
 var PtrCmdLn : ads of lstring(128);  {Far pointer to command line}
     PtrAllocTop : ads of word; {Pointer to last allocated segment}

     cesxqq [extern] : word; {Segment value of Program Segment Prefix}

 begin
     PtrCmdLn.s    := cesxqq; {PSP's segment assigned to ptr's .Segment}
     PtrAllocTop.s := cesxqq;
     PtrCmdLn.r    := 128; {PSP's offset 128 has copy of command line}
     PtrAllocTop.r := 2;   {PSP's offset 2 contains top allocated seg}
     writeln;
     writeln('Command line of program         = ',PtrCmdLn^);
     writeln('Last segment allocated from DOS = ',PtrAllocTop^:6)
 end.


 219. Passing Arguments into a Pascal Program

 Product Version(s): 3.30 4.00
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 26-SEP-1989    ArticleIdent: Q47818

 Microsoft Pascal provides an easy method to pass command-line
 arguments into a Pascal program. One of the functions of the Pascal
 start-up code is to parse the command line for arguments. These
 arguments are then passed into the program just as if they were being
 passed in as parameters, their associated names appearing on the
 PROGRAM line. The parameter types should be specified in the global
 variable section of the program. This is documented starting on Page
 295 of the "Microsoft Pascal 4.00 Reference Manual."

 The parameters "input" and "output" receive special treatment by the
 start-up code and therefore should not be declared in the variable
 section. They should, however, be included in the parameter list.

 Each argument must be of simple type (INTEGER, REAL, etc.) or of
 STRING, LSTRING, or FILE type. All type checking/conversion is
 performed by the start-up code. If arguments are not specified on the
 command line or if the arguments are of the wrong type, you will be
 prompted for the correct argument(s).

 The following program demonstrates the use of command-line arguments:

 PROGRAM Add(input, output, i1, i2, txt);

 VAR
   txt : LSTRING(20);
   i1,
   i2  : INTEGER;

 BEGIN
   writeln(txt,': ',i1+i2);
 END.

 Program execution appears as follows:

 c:\>add 5 10 the sum is
 the sum is:         15


 220. At Sign (@) Same As Caret (^)

 Product Version(s): 4.00   | 4.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified: 18-SEP-1989    ArticleIdent: Q46171

 For keyboards that do not have the caret key (^), the "at" sign (@)
 may be substituted. These symbols are synonymous and will generate
 identical code. The caret sign is used in referencing a file or
 pointer variable.

 The following program demonstrates the use of this symbol:

 PROGRAM foooo (input,output);

 VAR
   f : file of integer;
   x : @integer;        { same as x : ^integer; }

 BEGIN
   new (x);
   x@ := 87;            { same as x^ := 87; }

   assign (f, 'data');
   rewrite (f);

   f@ := x@;            { same as f^ := x^; }
   put (f);
 END.


 221. Accessing Variables Declared in a Pascal Interface File

 Product Version(s): 4.00   | 4.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | docerr
 Last Modified: 26-SEP-1989    ArticleIdent: Q48280

 Question:

 I am trying to access variables that I have declared in a Microsoft
 Pascal Version 4.00 interface file. Pages 142 and 306 of the
 "Microsoft Pascal Reference Manual," imply that variables declared in
 an interface file are automatically given the PUBLIC attribute. Does
 this mean that I can declare the variables in my interface file,
 include that interface file in my main and implementation files, and
 with the USES statement in my main file I will then have access to
 those variables? When I try to do this I receive compiler errors in
 both the main and implementation files, indicating that the variable
 is an unknown symbol.

 Response:

 The documentation is incorrect in this case. The only way to make
 variables declared in an interface file global and accessible to the
 main and implementation files is to include the variables in the
 constituent list along with the procedures and functions.

 The following code gives an example of declaring a function and a
 variable in an interface file and the usage of the implementation
 file:

 Interface File
 --------------

 INTERFACE;
 UNIT TESTUNIT (known,n);  { variable and function in the constituent list }
 VAR  n : INTEGER;         { variable to be made global }
 FUNCTION known : BOOLEAN; { function to be made global }
 BEGIN
 { BEGIN implies initialization code in the implementation file }
 END;

 Implementation File
 -------------------

 {$INCLUDE:'INTER'}
 IMPLEMENTATION OF TESTUNIT;

 FUNCTION known; { note that parameters and attributes are NOT listed again }
 BEGIN
     known := TRUE;
 END;

 { initialization code }
 BEGIN
     n := 10;
 END.

 Main File
 ---------

 {$INCLUDE:'INTER'}
 PROGRAM test(input,output);
 USES TESTUNIT (known,n);

 BEGIN
     if (n = 10) then          { n is declared in the interface file and }
         writeln('10')         { initialized in the implementation file }
     else
         writeln('unknown');
     if known then             { known is also from the interface and }
         writeln('known')      { implementation files }
     else
         writeln('unknown');
 END.

 This is compiled by the following:

    pl mainprogram.pas implementation.pas

 When the program is run, the following is output to the screen:

    10
    known

 More information on using Units and Interfaces can be found in the
 "Microsoft Pascal Reference Manual" starting on Page 300. Additional
 information on "Units and Interfaces: Examples" is available as an
 application note and can be requested by calling the the Microsoft
 Product Support at [phone].


 222. The /Fl Switch Is Not Recognized in the Environment Variable

 Product Version(s): 4.00   | 4.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified: 26-SEP-1989    ArticleIdent: Q48841

 To produce a source listing for your program with the Microsoft C Compiler,
 you can specify the /Fs switch in the CL environment variable.
 However, if you try to specify the /Fl switch with Pascal Version 4.00
 in the PL environment variable, the compiler just ignores the switch.

 PL's /Fl switch does not behave the same as CL's /Fs switch. The PL
 driver ignores the /Fl switch if it is specified in the PL environment
 variable. Another difference is that the /Fl applies only to the first
 Pascal source file that follows the option. It must be used once for
 each source file that you want listed. The /Fs switch for the CL
 driver creates source listings for all source files.

 The following command produces a source listing for test1.pas only:

    PL /Fl test1.pas test2.pas

 To produce a source listing for both source files, give the following
 command:

    PL /Fl test1.pas /Fl test2.pas


 223. Long Strings Displayed Incorrectly in Debug Window

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist1.00
 Last Modified: 10-OCT-1989    ArticleIdent: Q49115

 If a string is so long that it cannot be displayed in the
 255-character line allowed in the debug window, the string is
 truncated. QuickPascal should place ellipses (...) at the end of a
 truncated string to make it clear that the line was truncated.

 To reproduce this problem, use the following code and follow the steps
 outlined below:

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

 program longexamp;

 var longchar: string[255];

 begin
    longchar := 'This is information being put into a string to ';
    longchar := longchar + 'test Quick Pascal handling long ';
    longchar := longchar + 'strings.  Information could also be ';
    longchar := longchar + 'put into the string using a for next ';
    longchar := longchar + 'loop.  This method is being used, ';
    longchar := longchar + 'however, for simplicity.  The rest ';
    longchar := longchar + 'of this text is merely useless filler ';
    longchar := longchar + 'material of no consequence.  ';
 end.

 Use the following steps to reproduce this problem:

 1. Put a watch on the string longchar using the debug watch window.

 2. Move to the watch window using the F6 key.

 3. Using the arrow keys, place the cursor on the line containing
    "longchar".

 4. Press the END key to move the cursor to the end of the string.

    Note that the line is truncated without ellipses.

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


 224. "USER" Is Not a Valid Filename

 Product Version(s): 3.20 3.3x 4.00 | 4.00
 Operating System:   MS-DOS         | OS/2
 Flags: ENDUSER |
 Last Modified: 30-NOV-1989    ArticleIdent: Q49570

 Microsoft Pascal does not open a file if the filename is called
 "USER". The word USER is a special filename that Microsoft Pascal
 recognizes for reading from the keyboard and writing to the screen.

 This is documented on Page 45, Section 5.2, of the "Microsoft Pascal
 Compiler User's Guide".

 The following code demonstrates this feature in Microsoft Pascal:

 program File_test;

 var fh : Text;

 Begin
     assign (fh, 'USER.TXT');
     rewrite (fh);
     writeln (fh, 'This is a test file');
     close (fh);
 End.

 When you run this program, the string 'This is a test file' is printed
 to the screen. The file USER.TXT is not created because USER is a
 special filename that Microsoft Pascal uses to write to the screen.


 225. PASCAL.LIB Does Not Exist in Pascal 4.00

 Product Version(s): 4.00   | 4.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | docerr
 Last Modified: 30-NOV-1989    ArticleIdent: Q50338

 On Page 30 of the "Microsoft Pascal Compiler for the MS-DOS Operating
 System User's Guide," there is a documentation error for Version 4.00.
 The reference to PASCAL.LIB is correct for Version 3.20 and Version
 3.3x, but should be LIBPASER.LIB for real mode and LIBPASEP.LIB for
 protected mode in Version 4.00.


 226. Pascal 4.00: Compiler Treats Far Index As Near

 Product Version(s): 4.00   | 4.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | buglist4.00 subscript
 Last Modified:  4-JAN-1990    ArticleIdent: Q51519

 The example below demonstrates a problem when using a far index with
 the Microsoft PASCAL Compiler Version 4.00. The error occurs in
 compiling line 24 of the source file. In that line, IDX is used as a
 memory offset index to the address pointed to by the ADSMEM component
 of FAR_STRING.

 First the ES register is loaded with the segment of FAR_STRING, then
 loaded with the segment to which FAR_STRING.STR_ADS points. The ES is
 loaded with the segment in which IDX is located, without saving the
 previous segment address.

 By the time of the MOV to AL, ES incorrectly points to IDX and so
 cannot correctly access a byte within the FAR_STRING.STR_ADS' memory
 area.

 Changing the index from far to near (VARS to VAR) corrects the
 problem.

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

 The following code and assembly listing demonstrate the problem:

 Compile options: pl /c /Fc farsub.pas libpas7p.lib

 Source Code
 -----------

 MODULE BUG;

 {$LIST-}          { Set default listing behavior. }
 {$DEBUG-}         { Turn off all debug. }
 {$LINESIZE:132}   { Listing width. }
 {$REAL:8}         { All reals are 8 bytes. }
 {$FLOATCALLS-}    { Inline floating point operations. }
 {$SYMTAB-}

 TYPE
   FAR_STRING_TYPE = RECORD
     MAX_LEN : WORD;
     STR_ADS : ADSMEM;
     STR_LEN : WORD;
     END;

 FUNCTION  FIND_3
  (CONSTS FAR_STRING:FAR_STRING_TYPE;
  VARS IDX:WORD):BOOLEAN;

   BEGIN
   WHILE IDX < FAR_STRING.STR_LEN DO
     BEGIN
     IF FAR_STRING.STR_ADS^[IDX] = 3 THEN
       BEGIN
       BREAK;
       END
     ELSE
       BEGIN
       IDX := IDX + 1;
       END;
     END;
   FIND_3 := TRUE;
   END;

 END.  { MODULE BUG. }

 Object Code
 -----------

 L21:

 Procedure/Function : FIND_3

     ** 000001    PUSH      BP
     ** 000002    MOV       BP,SP
     ** 000004    SUB       SP,0002H
     ** 000008    PUSH      DI
     ** 000009    PUSH      SI
 L22:
 I4:
     ** 00000A    LES       DI,[BP].0AH
     ** 00000D    MOV       AX,ES:06H[DI]
     ** 000011    LES       SI,[BP].06H
     ** 000014    CMP       AX,ES:[SI]
     ** 000017    JBE       I5            !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
 L24:                                     ! Pascal 4.0 created a bug here.
     ** 000019    LES       DI,[BP].0AH   ! DI,DWord Ptr [FAR_STRING]
     ** 00001C    LES       BX,ES:02H[DI] !
     ** 000020    LES       DI,[BP].06H   ! DI,DWord Ptr [IDX]
     ** 000023    MOV       DI,ES:[DI]    !
     ** 000026    MOV       SP,AX         !
     ** 000028    MOV       AL,ES:[BX][DI]! ES points to IDX's segment;
     ** 00002B    XOR       AH,AH         !  not to FAR_STRING.STR_ADS's
     ** 00002D    CMP       AX,0003H      !  segment as it should.
     ** 000030    JNE       I6            !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
 L26:
     ** 000032    JMP       I5
 L27:
     ** 000034    JMP       I7
 I6:
 L30:
     ** 000036    LES       DI,[BP].06H
     ** 000039    INC       ES:[DI]
 L31:
 I7:
 L32:
     ** 00003C    JMP       I4
 I5:
 L33:
     ** 00003E    MOV       [BP].FEH,01H
 L34:
 I3:
     ** 000042    MOV       AX,[BP].FEH
     ** 000045    POP       SI
     ** 000046    POP       DI
     ** 000047    MOV       SP,BP
     ** 000049    POP       BP
     ** 00004A    LRET      0008H
 L36:

 Procedure/Function : BUG

     ** 00004D    PUSH      BP
     ** 00004E    MOV       BP,SP
     ** 000050    SUB       SP,0004H
     ** 000054    PUSH      DI
     ** 000055    PUSH      SI
     ** 000056    MOV       STKBQQ,BP
 I8:
     ** 00005A    POP       SI
     ** 00005B    POP       DI
     ** 00005C    MOV       SP,BP
     ** 00005E    POP       BP
     ** 00005F    LRET


 227. Pascal 4.00 Supports COM1:

 Product Version(s): 4.00   | 4.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified: 30-NOV-1989    ArticleIdent: Q50476

 The communications port COM1: is accessible by file operations in
 Pascal Version 4.00. To access this device, you must assign a file to
 "COM1" and call the REWRITE function to open it. After this is done,
 you can read and write characters to the communications port just as
 if it were a file. Remember, COM1: is an unbuffered device; therefore,
 characters can be lost at high baud rates.

 The following example compiled with Pascal Version 4.00 under both
 OS/2 and MS-DOS.

 PROGRAM SendOutputToCom1(input,output);

 var f : text;

 BEGIN
   assign(f, 'com1');
   rewrite(f);
   writeln(f, 'Hi com1...');
 END.


 228. Passing PROCEDUREs as Arguments Can Hang Computer

 Product Version(s): 4.00
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified:  4-JAN-1990    ArticleIdent: Q51584

 The computer will hang when the main program calls Proc2 with Proc1 as
 a parameter. In addition, the following must be true:

    Proc1 is the first procedure in the source code file.
    Proc2 calls Proc1 which is passed as an argument.

 There are two workarounds, as follows:

 1. Make Proc1 a [PUBLIC] procedure.

 2. Don't allow Proc1 to be the first procedure in the source file
    (i.e., there must be at least one procedure defined above Proc1 in
    the source file).

 The following program illustrates the above problem with the two
 workarounds demonstrated in the commented out sections.

 PROGRAM Hang (INPUT, OUTPUT);

    { PROCEDURE Dummy;
        BEGIN
           WriteLn ('This Procedure declaration must be');
           WriteLn ('uncommented to implement workaround #2');
        END; }

    PROCEDURE Proc1 { [PUBLIC] };
       BEGIN
          WriteLn ('The above keyword, [PUBLIC], must be');
          WriteLn ('uncommented to implement workaround #1');
       END;

    PROCEDURE Proc2 (PROCEDURE ProcArg);
       BEGIN
          ProgArg;     { Calling ProcArg }
       END;

    BEGIN  { main program }
       Proc2 (Proc1);  { Cause Proc2 to call Proc1 }
    END.


 229. No Appendix H in the Microsoft Pascal Reference Manual

 Product Version(s): 4.00   | 4.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | docerr
 Last Modified: 26-FEB-1990    ArticleIdent: Q51747

 On Page 124 of the "Microsoft Pascal Compiler for the MS-DOS Operating
 System User's Guide" supplied with Microsoft Pascal Version 4.00, it
 incorrectly states the following:

    In Microsoft Pascal, the message describes the error, and the
    number can be used to look up more information (see Appendix H,
    "Messages," in the Microsoft Pascal Reference Manual).

 Also, on Page 96 of the "Microsoft Pascal Reference Manual," it
 incorrectly states the following:

    See Appendix H, "Messages," for a complete listing of error
    messages and warnings.

 There is no Appendix H in the reference manual. The correct location
 for error messages is Appendix F of the "Microsoft Pascal Compiler for
 the MS-DOS Operating System User's Guide," starting on Page 221.


 230. User Error #905 Program Size Too Large

 Product Version(s): 4.00   | 4.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | docerr
 Last Modified:  4-JAN-1990    ArticleIdent: Q51762

 In Pascal, user error #905 is not documented. The entire error
 is as follows:

    user error #905  Program size too large (exceeds 64K bytes of code)

 This error is generated in pass two of the compiler. In Pascal, each
 module must have less than 64K of code, though a multiple module
 program can be larger than this.

 Chapter 8 ("Compiling and Linking Large Programs") of the "Microsoft
 Pascal Compiler for the MS-DOS Operating System User's Guide," Version
 4.0, explains the full process of setting up multiple module programs.


 231. Manual Setup for Microsoft Pascal Version 4.00

 Product Version(s): 4.00   | 4.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified: 14-MAR-1990    ArticleIdent: Q51900

 The following information demonstrates how to manually set up
 Microsoft Pascal Version 4.00 for DOS and OS/2 mode on a hard drive.
 It will show you how to set up in the same way as the SETUP.EXE
 program.

 This information demonstrates how to set up Microsoft Pascal Version
 4.00 under the directory "PASCAL" on Drive C. You may change the
 directory name or the drive name.

  1. Create the following directories:

        C:\PASCAL\BINR      (Create only if you want DOS mode.)
        C:\PASCAL\BINB
        C:\PASCAL\BINP      (Create only if you want OS/2 mode.)
        C:\PASCAL\LIB
        C:\PASCAL\INCLUDE
        C:\PASCAL\TMP
        C:\PASCAL\LIB
        C:\PASCAL\INIT
        C:\PASCAL\WORK

  2. Add the following to your AUTOEXEC.BAT file or a separate batch
     file:

        SET PATH=C:\PASCAL\BINB;C:\PASCAL\BINR  (for DOS mode)
        or
        SET PATH=C:\PASCAL\BINB;C:\PASCAL\BINP  (for OS/2 mode)
        or
        SET PATH=C:\PASCAL\BINB;C:\PASCAL\BINR;C:\PASCAL\BINP (for DUAL mode)

        SET INCLUDE=C:\PASCAL\INCLUDE
        SET LIB=C:\PASCAL\LIB
        SET TMP=C:\PASCAL\TMP
        SET INIT=C:\PASCAL\INIT

     Note: It is important that you do NOT add spaces inside these
     commands. For example, "SET LIB = C:\PASCAL\LIB" or
     "SET LIB=C:\PASCAL\LIB" are incorrect. The correct method for setting
     this path is "SET LIB=C:\PASCAL\LIB".

     Note: For the OS/2, if you want these changes to be global for all
     screen groups, include these commands in your CONFIG.SYS file.
     Otherwise, follow the above procedure, and then rename your
     AUTOEXEC.BAT to AUTOEXEC.CMD.

  3. Add the following lines to your CONFIG.SYS file, if they do not
     already exist:

        FILES=20
        BUFFERS=20

     (You must reboot after this step for these changes to take effect.)

  4. Copy the following files into C:\PASCAL\BINR. (You can skip this
     step if you do not want to install for DOS mode.)

        File                           Distribution Disk
        ----                           -----------------

        ERROUT   EXE    10729          Setup and Compiler
        EXEMOD   EXE    12336          Setup and Compiler
        EXEPACK  EXE    14803          Setup and Compiler
        SETENV   EXE    10870          Setup and Compiler
        EXEC     EXE     9299          Library 2 disk
        CV       EXE   263890          Microsoft CodeView for MS-DOS
        CV       HLP    22444          Microsoft CodeView for MS-DOS
        MOUSE    COM    14551          Microsoft CodeView for MS-DOS
        CALLTREE EXE    31233          Microsoft Editor
        M        EXE    94821          Microsoft Editor

  5. Copy the following files into C:\PASCAL\BINB:

        SETUP    EXE    81181          Setup and Compiler
        87       EXE     8798          Setup and Compiler
        BIND     EXE    36946          Setup and Compiler
        ECH      EXE    19351          Setup and Compiler
        EXP      EXE    32220          Setup and Compiler
        EXEHDR   EXE    29942          Setup and Compiler
        IMPLIB   EXE    30166          Setup and Compiler
        PAS1     EXE   139623          Utilities
        PAS2     EXE   131199          Utilities
        PAS3     EXE    40401          Utilities
        MAKE     EXE    38613          Utilities
        LINK     EXE   117001          Examples
        PL       EXE    31861          Examples
        RM       EXE    24884          Examples
        UNDEL    EXE    30046          Library 1 disk
        LIB      EXE    49661          Library 2 disk
        ILINK    EXE    88929          Library 2 disk
        CVPACK   EXE    49400          Microsoft CodeView for MS-DOS
        MEGREP   EXE    31915          Microsoft Editor

  6. Copy the following files into C:\PASCAL\BINP. (You can skip this
     step if you do not want to install for OS/2 mode.)

        CVP      EXE   233249          Microsoft CodeView for MS OS/2
        CVP      HLP    22444          Microsoft CodeView for MS OS/2
        MEP      EXE    97063          Microsoft Editor

  7. Copy the following files into C:\PASCAL\INCLUDE:

        FINK             3472          Examples
        FINKXU           4331          Examples
        FINU             5482          Examples
        CLOCK    INT      308          Examples
        INTRP    INT      225          Examples
        PORT     INT      129          Examples
        BSE      INT     1062          Examples
        BSEDOS   INT    39921          Examples
        BSEERR   INT    18185          Examples
        BSESUB   INT    20490          Examples
        OS2      INT      716          Examples
        OS2DEF   INT     1835          Examples

  8. Copy the following files into C:\PASCAL\INIT:

        WS       DLL     2609          Microsoft Editor
        WS       ZXT     2084          Microsoft Editor

  9. To create the TOOLS.INI file, choose the type of editor you would
     like to use (these files are located on the "Microsoft Editor"
     distribution disk):

        BRIEF.INI
        EPSILON.INI
        QUICK.INI

     Then, rename the file you choose to TOOLS.INI, and place it in the
     INIT subdirectory pointed to by the "SET INIT=C:\INIT" environment
     variable.

 10. Copy the following files into C:\PASCAL\WORK:

        README   DOC    48065          Setup and Compiler
        PASEXEC  INC     4450          Examples
        DEMOEXEC PAS     1211          Examples
        PRIMES   PAS      634          Examples
        SORTDEMO PAS    27342          Examples
        MAKESORT BAT     1326          Examples
        MAKESORT CMD     1313          Examples
        EMOEM    ASM    12125          Examples
        ENTX6L   ASM    10863          Examples
        ENTXSTUB ASM      394          Examples
        EXT      DOC    15877          Microsoft Editor
        EXT      H       8730          Microsoft Editor
        EXTHDR   OBJ     1893          Microsoft Editor
        EXTHDRP  OBJ     2021          Microsoft Editor
        SKEL     C       2457          Microsoft Editor
        SKEL     DEF      211          Microsoft Editor

 11. Copy all the files from the Library 1 and Library 2 disks into the
     C:\PASCAL directory. This directory will be used to temporarily
     store the component libraries.

 12. There is a file called MAKELIB.BAT, which will automatically build
     the libraries for DOS and/or OS/2 mode. By typing "MAKELIB" by
     itself at the DOS prompt with no arguments, it will show a list of
     parameters to use when building a library.

     The following is an example to build a DOS emulator library:

        Type:  C:\PASCAL> MAKELIB C:\PASCAL DOS \LIB EMULATOR

     After the desired libraries have been created, delete all the
     files in C:\PASCAL by changing the working directory to C:\PASCAL
     and typing DEL *.*. This will regain the lost disk space used by
     the component libraries.


 232. Setting Up Pascal 4.00 on a Dual Floppy Machine

 Product Version(s): 4.00   | 4.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified: 10-JAN-1990    ArticleIdent: Q51936

 Question:

 How do I set up Pascal Version 4.00 on dual 5.25-inch floppy disks?

 Response:

 The following is one configuration that allows you to run the Pascal
 compiler with a minimum of disk swaps. This is only one of a large
 number of possible configurations; feel free to change any settings as
 you like.

 This particular configuration takes five 5.25-inch floppy disks. The
 file to place on the floppy disk is listed on the left, and its source
 disk is listed on the right.

 Disk One: Compiler
 ------------------

    File                          Source Disk
    ----                          -----------

    PAS1.EXE                      Disk 2: Utilities
    PAS2.EXE                                "
    PAS3.EXE                                "
    PL.EXE                        Disk 3: Examples

 Disk Two : Utilities 1
 ----------------------

    File                          Source Disk
    ----                          -----------

    ERROUT.EXE                    Disk 1: Setup and Compiler
    EXEMOD.EXE                              "
    EXEPACK.EXE                             "
    SETENV.EXE                              "
    EXEC.EXE                      Disk 5: Libraries 2
    MOUSE.COM                     Disk 6: CodeView for MS-DOS
    CALLTREE.EXE                  Disk 8: Microsoft Editor
    M.EXE                                   "
    87.EXE                        Disk 1: Setup and Compiler
    ECH.EXE                                 "
    EXP.EXE                                 "
    EXEHDR.EXE                              "
    IMPLIB.EXE                              "
    RM.EXE                        Disk 3: Examples

 Disk Three: Utilities 2
 -----------------------

    File                          Source Disk
    ----                          -----------

    MAKE.EXE                      Disk 2: Utilities
    LINK.EXE                      Disk 3: Examples
    ILINK.EXE                     Disk 5: Libraries 2
    UNDEL.EXE                     Disk 4: Libraries 1

 Disk Four: CodeView
 -------------------

    File                          Source Disk
    ----                          -----------

    CV.EXE                        Disk 6: CodeView for MS-DOS
    CV.HLP                                  "
    CVPACK.EXE                              "

 Disk Five: Libraries
 --------------------

    File                          Source Disk
    ----                          -----------

    LIB.EXE                       Disk 5: Libraries 2

 Notice that the Libraries disk contains only LIB.EXE, the library
 manager. You need to build the run-time library from the floppy disks,
 using the following procedure:

 1. Enter the following line at the DOS prompt:

       set path=a:\;b:\

 2. Insert the Libraries disk into Drive B. Put the Setup and Compiler
    source disk in Drive A. After making sure the current drive is Drive
    A, type the following:

       setup /l

    The /l option only builds libraries; it does not install the
    compiler. The Setup program invoked with the /l option only asks
    questions that pertain to the run-time libraries that you want
    built. The resulting combined library is placed on your Libraries
    disk along with modules to which you may want to link in the
    future.

 3. Add the following lines to your AUTOEXEC.BAT file:

       SET TMP=b:\
       SET INCLUDE=b:\
       SET LIB=b:\

 4. Add the following lines to your CONFIG.SYS file, if they do not
    already exist:

       FILES=20
       BUFFERS=20

 5. You must reboot for the changes in the CONFIG.SYS file to take
    effect.

 You may want to write a test program to compile and link in order to
 familiarize yourself with the disk swapping process.

 This is by no means the only way to set up Pascal 4.00 on a 360K
 floppy disk system, but it has been tested and works correctly. Feel
 free to change any settings or disk contents as you see fit, so that
 your environment is set up as you would like.


 233. Increasing the Maximum Number of Open Files in Pascal 4.00

 Product Version(s): 4.00
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified:  4-JAN-1990    ArticleIdent: Q52104

 The following procedure allows you increase the maximum number of open
 files running DOS Version 3.3 or OS/2 Version 1.1:

 1. Increase the number of file handles, starting at 20 for this
    example, by editing the startup source file CRT0DAT.ASM. This is
    located on the Startup Source Code disk. Change the following line
    to the desired amount.

       _NFILE_ = 20

 2. Increase the per-process limit in the DOS version of the same file,
    CRT0DAT.ASM, by uncommenting the code duplicated below (remove the
    ';'):

                      ;     mov     ah,67h
                      ;     mov     bx,_NFILE_
                      ;     callos

    In the OS/2 version of CRT0DAT.ASM, you must enable the line

                      ;extrn  DOSETMAXFH:far

    and also enable the code below in the same manner:

                      ;     mov     ax,_NFILE_
                      ;     push    ax
                      ;     call    DOSSETMAXFH

 3. Increase the system-wide limit by editing your CONFIG.SYS. Change
    the following line to the desired amount:

       FILES=20

 4. Assemble the modified CRT0DAT.ASM using the batch file STARTUP.BAT
    on the Startup Source Code disk. This file also contains sample
    command lines.

 5. To use the new CRT0DAT.OBJ, either use the LIB utility to replace
    the .OBJ in the appropriate Pascal run-time library, or explicitly
    link your program with it.


 234. ADS and ADR: Pascal Operators -- Documentation Supplement

 Product Version(s): 3.20 3.30 4.00 | 4.00
 Operating System:   MS-DOS         | OS/2
 Flags: ENDUSER | docsup
 Last Modified: 16-JAN-1990    ArticleIdent: Q57494

 The ADS and ADR operators in Pascal evaluate to the address of the
 object to which they are applied. ADS (ADdress Segmented) evaluates to
 the full address (segment|offset) of the object, and ADR (ADdress
 Relative) evaluates only to the offset into the default data segment.
 These operators have the same precedence as the Pascal NOT operator,
 and have a higher precedence than the other Pascal operators.

 Note 1: Pascal Version 3.20 used incorrect precedence rules for the ADS
 and ADR operators. See Note 2 below for details.

 Documentation for ADS and ADR can be found in the "Microsoft Pascal
 Reference Manual" on Pages 104-109 and 147, and in the "Microsoft
 Pascal User's Guide" on Pages 139-141.

 Syntax of ADS/ADR Expressions
 -----------------------------

 The ADS and ADR operators are used to take the address of any symbol
 or expression. For example,

    ADS x
 and
    ADS (i + j * k)

 are legal expressions for all Pascal versions except 3.20. Parentheses
 must be used in the second example because ADS (or ADR) has a higher
 precedence than the + and * operators.

 Note 2: In Version 3.20, the ADS and ADR operators would evaluate the
 entire expression following it, disregarding precedence. Therefore,
 the following expression

    ADR a + b   (where a and b are variables)

 would be incorrectly evaluated as

    ADR (a + b)

 rather than

    (ADR a) + b

 as the correct precedence rules would dictate.

 Syntax of ADS/ADR Declarations and Statements
 ---------------------------------------------

 ADS and ADR can be used both as type clause prefixes (declaring a type
 as an ADR of something, for example, a pointer) and as prefix
 operators (ADR of a variable, for example, taking the address). The
 following code example displays this:

 PROGRAM TEST(INPUT,OUTPUT);

 TYPE ARRAY_TYPE     = ARRAY [1..10] OF INTEGER;

 VAR  CHAR_VAR       : CHAR;
      ADR_CHAR       : ADR OF CHAR;           { ADR used as type
                                                clause prefix    }
      INT_ARRAY      : ARRAY_TYPE;
      ADS_ARRAY      : ADS OF ARRAY_TYPE;

 BEGIN
      CHAR_VAR := 'Z';
      INT_ARRAY[1] := 2;

      ADR_CHAR := ADR CHAR_VAR;               { ADR used as prefix
                                                operator         }
      ADS_ARRAY := ADS INT_ARRAY;

      WRITELN(ADR_CHAR^, ADS_ARRAY^[1]);      { up arrow (^) used
                                                to dereference
                                                address type     }
 END.

 The output for this program would be as follows:

    Z       2

 Note 3: If you want to return the actual physical address of any
 object, use the field notations .s and .r for the segment and relative
 offset addresses, respectively. However, these addresses are expressed
 only in decimal notation by the compiler. For example, you could add
 the following line to the above program to obtain the relative offset
 address of CHAR_VAR and the segment and relative offset addresses of
 ARRAY_TYPE:

    WRITELN(ADR_CHAR.R, ADS_ARRAY.R, ADS_ARRAY.S);

 The output for this line would be similar to the following:

    66      70      25478

 This feature is documented in the "Microsoft Pascal Reference Manual"
 on Pages 105-107.

 ADS with Functions
 ------------------

 When taking the address of a function, the usage of parentheses
 changes the meaning of the expression. The expression

    ADS func

 (where "func" is a function) will evaluate to the address of the
 function a, and the expression

    ADS (func)

 will evaluate to the address of the return value of the function.

 When using ADS to get the address of a function or procedure, ADS will
 return a value of the type ADSFUNC or ADSPROC, respectively. These two
 predefined types are compatible with C function pointers.

 To call a function or procedure with variables or parameters of these
 types, their value must be passed, externally, to a non-Pascal
 routine, which in turn will call the function or procedure. For more
 information on ADSFUNC and ADSPROC, see the "Microsoft Pascal User's
 Guide," Page 140.


 235. Pascal 4.00 Setup Cannot Find WIN86EM.LIB

 Product Version(s): 4.00    | 4.00
 Operating System:   MS-DOS  | OS/2
 Flags: ENDUSER |
 Last Modified: 15-FEB-1990    ArticleIdent: Q58643

 An unexpected warning can occur with the Microsoft Pascal Version 4.00
 Setup program when the compiler is being installed with options to
 write Windows applications.

 If you answer yes to the following prompt

    Remove STACK segment from library for Windows? [y]

 Setup will attempt to copy a file called WIN86EM.LIB from the Library
 1 Disk. The file does not exist. Setup will issue a warning message
 such as the following:

   WARNING: File copy failed : A:\win86em.lib to
   C:\PASCAL\lib\win86em.lib

 Although the file WIN86EM.LIB does not exist, the Library 1 Disk does
 contain the file WIN87EM.LIB. This is the file that Setup should have
 attempted to copy.

 The solution is to copy the file WIN87EM.LIB into the Pascal LIB
 subdirectory. WIN87EM.LIB is not intended to be included in any of the
 combined libraries so there is no danger of the Setup program having
 problems when it creates the combined libraries. WIN87EM.LIB is meant
 to be a stand-alone library file in the LIB subdirectory.


 236. The PUBLIC and EXTERN Attributes in Mixed-Language Programming

 Product Version(s): 4.00
 Operating System:   OS/2
 Flags: ENDUSER | s_c L4001
 Last Modified: 26-FEB-1990    ArticleIdent: Q58648

 The PUBLIC attribute, when applied to variables in Microsoft Pascal
 Version 4.00, indicates that a variable may be accessed by other
 loaded modules, and instructs the compiler to make a variable visible
 and available to other modules, by implication allocating memory for
 the variable.

 This behavior is in contrast to the EXTERN attribute, which identifies
 to the compiler a variable that resides in some other loaded module,
 instructing the compiler not to allocate memory for the variable
 because it has been declared (and memory allocated for it) in another
 module and will be resolved by the linker at link time.

 This behavior is not always consistent when performing mixed-language
 calls between C and Pascal under OS/2. When passing pointer variables
 that have been allocated space in a shared memory segment, although
 the variable has been declared (far) in the main C calling module, it
 must also be declared PUBLIC in the Pascal module. Failure to do so
 will result in the following linker warning:

    PASCAL1.OBJ(PASCAL1.pas) : warning L4001: frame-relative fixup,
    frame ignored near 000A in segment NAME pos: 23C Record type:
    75E8 target external 'identifier'

 The warning is defined in the "Microsoft CodeView and Utilities
 Software Development Tools for MS OS/2 and MS-DOS Operating Systems
 Update" as follows:

    A reference is made relative to a segment which is different from
    the target segment of the reference. For example, if _foo is
    defined in segment _TEXT, the instruction "call DGROUP:_foo" will
    result in this warning. The frame DGROUP is ignored, so the linker
    will treat the call as if it were "call _TEXT:_foo".

 Under OS/2, if multiple pointer variables are using the same shared
 segment, the above warning may lead to a protection violation if the
 executable is run. This may be somewhat counter-intuitive according to
 the definitions of PUBLIC and EXTERN detailed in the "Microsoft Pascal
 Reference Manual" for Version 4.0, Section 11.5.2. The following code
 demonstrates the problem.

 Sample Code
 -----------

 { Pascal Module: compile with pl /c }

 MODULE PASCAL1;

 TYPE

     SAMPLE = RECORD
            DEC   : INTEGER;
            NAME  : ARRAY[1..3] OF INTEGER;
            SCALE : REAL
          END;

 SARRAY = ARRAY[1..100] OF SAMPLE;

 VAR

          FOO  [C, EXTERN]:  ADS OF SARRAY;

          { Change EXTERN to PUBLIC to correct the problem }

          GOO             :  ADS OF SARRAY;

 PROCEDURE DEMO(A:ADSMEM);

  BEGIN
    GOO := FOO;
    writeln('Hello World');
    writeln(GOO.S); { Observe the segment address for GOO }

  END;

 END.

 /* C module: compile with cl -c -AL */

 #define INCL_DOSPROCESS
 #define INCL_DOSMEMMGR
 #define SHRSEGNAME  "FOOBAR"
 #include <os2def.h>
 #include <bsedos.h>
 #include <stdio.h>
 #include <process.h>

 struct sample far *foo;
 /* Pointer to be passed back to pascal module */

 SEL SharedSel;

 extern pascal demo(struct sample far *);

 extern pascal pascal1;

 main()
 {

 /* allocate shared memory segment */
 DosAllocShrSeg(256, SHRSEGNAME, &SharedSel);

 /* foo allocated memory in shared segment */
 foo = (struct sample far *) MAKEP(SharedSel,0);

 demo(foo);    /* call Pascal procedure */

 DosFreeSeg(SharedSel);

 exit(0);
 }

 Compile each of the above modules separately and link with the
 following command:

    link /NOD /NOE pascal1+Cmodule,,,LLIBCE+OS2+LIBPASE;

 The above warning will be observed. If the EXTERN attribute for FOO is
 changed to PUBLIC, the program will link without warnings and will run
 correctly.


 237. Location and Description of File System Error Numbers

 Product Version(s): 3.x 4.00
 Operating System:   OS/2
 Flags: ENDUSER |
 Last Modified: 18-APR-1990    ArticleIdent: Q59988

 After opening a file in Pascal, you can check for file errors by
 verifying the .errs field of the file record. This field will either
 contain 0 (zero), which indicates no error, or a number between 1 and
 15. These error codes (1-15) are listed on Pages 257-258 of the
 "Microsoft Pascal Compiler for the MS-DOS Operating System User's
 Guide" for Version 4.0 manual under the section marked as follows:

    Runtime File System Errors(1000-1199)

 A number between 1-15 is returned in the .errs field of the Pascal
 file record, as shown in the following, indicating any errors that may
 have occurred while opening the file:

    f : text; {File}
    error : integer; {Receives error}
    error := f.errs; {Return a number 1-15}

 The value returned by f.errs may be one of the following:

  1 - Hard Data Error: Parity, CRC, check sum, etc.
  2 - Device Name Invalid: Unit/device/volume name, format, or number
  3 - Operation: Invalid operation (for example, RESET a printer)
  4 - File System: File system internal error
  5 - Device Offline
  6 - Lost File: File itself is no longer available.
  7 - File Name: Invalid syntax (name too long, etc.)
  8 - Device Full: Disk full, directory full, all channels allocated
  9 - Unknown Device
 10 - File Not Found
 11 - Protected File: Duplicate filename or file write-protected
 12 - File in Use: File in use, concurrency lock, already open
 13 - File Not Open: File closed, I/O to unopened FCB
 14 - Data Format: Data format error, decode error, range error
 15 - Line Too Long: Buffer overflow, line too long


 238. Writing to a segment:offset Memory Location Using MS Pascal

 Product Version(s): 4.00   | 4.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified: 15-AUG-1990    ArticleIdent: Q64806

 The following steps outline how to write directly to a specific
 segment:offset memory location using the Microsoft Pascal compiler
 version 4.00 (the information below is contained in the "Microsoft
 Pascal Reference Manual," Section 9.1.2, Pages 104-109):

 1. Declare a variable of type "ADS OF <type>", where <type> is the
    data type that you want to write; for example:

       var ptr : ads of byte;

 2. Set the segment and offset of the variable by using the ".s" and
    ".r" record elements; for example:

       ptr.s := 16#5F00;       { Segment value = 5F00 hex }
       ptr.r := 16#04CD;       { Offset value  = 04CD hex }

 3. To read and write from/to the address, use the dereference operator
    "^"; for example:

       ptr^  := 65;
       value := ^ptr;

 The sample program below was written in Microsoft Pascal and reads and
 writes bytes near memory location B800:0000 (hex), which is the start
 of standard video memory:

 Sample Code
 -----------

 program screen;

 var ptr   : ads of byte;  { The pointer variable }
     value : word;         { Something to read memory into }

 begin
   ptr.s := 16#b800;       { Assign the segment value of the pointer }
   ptr.r := 16#0000;       { Assign the offset value of the pointer }
   ptr^  := 65;            { Write 65 to location B800:0000 (hex) }

   ptr.r := 16#0024;       { Set the offset to a new value }
   value := ptr^;          { Read from location B800:0024 (hex) }
 end.

 Note: The sample program will only work under DOS. It will generate a
 GP fault under OS/2 because writing to video memory directly is
 prohibited under OS/2.


 239. Pascal 4.00 PC, SS, FP, and SP Can't Find Run-Time Errors

 Product Version(s): 4.00
 Operating System:   MS-DOS
 Flags: ENDUSER | SR# S900822-32 docerr
 Last Modified: 31-AUG-1990    ArticleIdent: Q65324

 When a run-time error occurs in the Microsoft Pascal 4.00 program, the
 program will display the values for the PC, SS, FP, and SP. The values
 are called the "machine error context" in the "Microsoft Pascal 4.0:
 User's Guide."

 The values generated by the program are incorrect, are not meaningful,
 and do not represent the values of the machines registers at the time
 the error occurred. Consequently, these values cannot be used to find
 run-time errors.

 On Page 225, the "Microsoft Pascal 4.0: User's Guide" incorrectly
 states that these values can be used to find run-time errors. In
 particular, it incorrectly states that you can use the Program Counter
 (PC) along with a linker map file (.MAP file) to find the routine in
 which the error occurred.

 The only way to easily find run-time errors in Pascal 4.00 programs is
 to compile and link the program for debugging in the CodeView
 debugger.

 This information applies to Microsoft Pascal 4.00 for MS-DOS and MS
 OS/2.


 240. SCO Now Supports All Versions of Pascal for XENIX

 Product Version(s): 3.30 3.31
 Operating System:   XENIX
 Flags: ENDUSER | SR# S900924-11
 Last Modified: 26-DEC-1990    ArticleIdent: Q65887

 The Santa Cruz Operation (SCO) has assumed responsibility for sales
 and support of all versions of the Microsoft Pascal Compiler
 (including versions 3.30 and 3.31) for the XENIX operating system.

 SCO is fully committed to the UNIX marketplace and solidly backs
 Microsoft applications and languages. SCO is also committed to
 updating and adding versions of the Pascal Compiler for XENIX.

 SCO has the resources required to support this product on a variety of
 configurations and terminals.

 Such support is not free. As is typical in the UNIX world, SCO charges
 for support on a variety of levels. A comprehensive explanation of the
 sales and support programs can be obtained directly from SCO at the
 following address:

    Support Department
    The Santa Cruz Operation
    400 Encinal Street
    Santa Cruz, CA  95061

    Phone Numbers: [phone] Support
                   [phone] Sales
                   [phone] Main Number


 241. Pascal Error 201 "Types Not Assignment Compatible" in UNIT

 Product Version(s): 4.00   | 4.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | SR# S900924-27 buglist4.00
 Last Modified: 26-DEC-1990    ArticleIdent: Q66138

 The error "201 Types Not Assignment Compatible" incorrectly occurs
 when an enumerated data type is used as an array index if the array is
 declared as a procedure parameter within a Pascal UNIT.

 This information applies only to the Microsoft Pascal Compiler version
 4.00 for MS-DOS and OS/2.

 Microsoft has confirmed this to be a problem with the Microsoft Pascal
 Compiler version 4.00. We are researching this problem and will post
 new information here as it becomes available.

 The error occurs only if all of the following conditions are met:

 1. A Pascal UNIT is being compiled.

 2. The array is a parameter to a Pascal PROCEDURE within the UNIT.

 3. An enumerated data type is used as an index to the array.

 The following code example reproduces the error:

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

 INTERFACE;
 UNIT FOO(PROC1);

      TYPE enum = (a,b,c,d,e);
           enarr = array[enum] of INTEGER;

      PROCEDURE PROC1(EnumArray : enarr);
 BEGIN
 END;

 IMPLEMENTATION OF FOO;

      TYPE enum = (a,b,c,d,e);
           enarr = array[enum] of INTEGER;

 PROCEDURE PROC1;
      VAR  en    : enum;
           local : enarr;
           x     : INTEGER;
      BEGIN
           FOR en := a TO e DO BEGIN
                WRITELN ( EnumArray[en]); { Error 201.}
                x := EnumArray[en];       { Error 201.}
                WRITELN ( local[en]);   { Compiles ok.}
                x := local[en];         { Compiles ok.}
           END;
      END;
 END.


 242. Trapping I/O Errors Using the "TRAP" Flag in Pascal 4.00

 Product Version(s): 4.00   | 4.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | SR# S901009-56
 Last Modified: 26-DEC-1990    ArticleIdent: Q66318

 When a file variable is defined within Pascal version 4.00, that file
 variable automatically has three associated flags that are not
 explicitly defined through a Record type. These three flags are
 accessed in the same way you would access a field within a Record
 Type:

 FileVar.Trap - Determines whether I/O errors should be trapped for this
                file.

 FileVar.Mode - Mode in which the File or Device was opened.

 FileVar.Errs - Error number, when an I/O error occurs if the Trap flag
                is set to "True".

 Utilizing the "Trap" and "Errs" flags, you can perform error trapping
 on all file or device I/O.

 This information applies to the Microsoft Pascal Compiler version
 4.00 for MS-DOS and OS/2.

 Once a File variable is assigned to a file or device, error trapping
 can be performed by setting the "Trap" flag to "True" and then
 checking the value of the "Errs" flag after I/O is performed on the
 file or device. If "Errs" is nonzero, an error has occurred allowing
 you to process the error. If the "Trap" flag is set to "False" and an
 I/O error occurs, the program will terminate with an I/O error.

 The following sample program demonstrates how to trap errors while
 printing to the standard device PRN. The same method is used for data
 files.

 Compile and Link with the following command:

    PL PrnTest.Pas

 PrnText.Pas
 -----------

 Program ErrorTrap;

 Var prn: Text; {Declare File variable of type Text
                 which will be used for the standard
                 device PRN}

 { This procedure will be called when the value of
   prn.Errs is non-zero following any I/O on prn.
   This procedure is not automatically called.
   The value of prn.Errs must be checked, and
   depending on its value, control should be
   passed to this Procedure. Prn.Errs must be
   set back to zero after the error has been
   processed to allow error trapping to continue. }

 Procedure ErrorHandler;
 Begin
   Writeln('An error occurred, Number: ', prn.Errs);
   prn.Errs:=0;
 End;

 Begin
   Assign(prn, 'PRN');  {Assign Standard device PRN to file
                         variable prn}

   prn.Trap:= True;     {Activate Error trapping for prn}

 {The following Writeln statement will generate an error
  because the file PRN has not yet been opened, but only
  associated with the device PRN. The flag Prn.Errs is
  then checked for a nonzero value and control is passed
  to the Error Handler Procedure if an error occurred.}

   Writeln(prn, 'This Should Not Print');
   If prn.Errs <> 0 Then ErrorHandler;

   ReWrite(prn);  {Open up the file (PRN device) so the
                   the following Writeln statement will
                   execute successfully.}

   Writeln(prn, 'This Should Print');
   Close(prn);
 End.


 243. Pascal Reply Letters: Appnotes BP0359, BP0360, BP0361

 Product Version(s): 3.13 3.20 3.30 3.3x 4.00 | 4.00
 Operating System:   MS-DOS                   | OS/2
 Flags: ENDUSER | S_QuickPas policy appnote BP0359 BP0360 BP0361
 Last Modified: 26-DEC-1990    ArticleIdent: Q66492

 Below are the three form letters that Microsoft sends in response to
 unsolicited letters from customers who have Pascal or QuickPascal:

    Appnote Number   Title
    --------------   -----

    BP0359           Pascal Suggestion Reply Letter
    BP0360           Pascal Question Reply Letter
    BP0361           Pascal Problem/Docerr Reply Letter

 This information applies to all Microsoft Pascal versions (including
 3.13, 3.20, 3.30, 3.3x, 4.00) and to Microsoft QuickPascal version
 1.00.

 Note: Page 1 of 2 is shown below for each reply letter. Page 2 of 2,
 the "Product Assistance Checklist," is the same for each reply letter,
 and is shown in a separate article found by querying for the following
 words:

    product and assistance and checklist

 BP0359: Pascal Suggestion Reply Letter
 --------------------------------------

 Dear PASCAL Customer:

 Thank you for your letter concerning your suggestion to our PASCAL
 language product. Although we are unable to respond to your technical
 questions by letter, we do forward your letters to our PASCAL
 development team. This procedure provides developers with customer
 feedback, which will in turn make Microsoft's products even better.
 Now that we can no longer respond to letters (unless solicited by
 Microsoft), we are providing the following new service:

 Our toll-line number, [phone], is available Monday through
 Friday (except holidays), 8 AM to 5 PM Pacific Standard Time, and is
 designed to answer questions about set up and installation procedures,
 problem reports, and documentation errors. We also address most
 programming, code debugging, and problem solving issues.

 There are many supplemental sources of information relating to the
 PASCAL languages, including reference guides and books published by
 Microsoft Press. Support is also available electronically through
 Microsoft OnLine and CompuServe. One of the features of these services
 is to provide access to the Microsoft Knowledge Base. The Microsoft
 Knowledge Base contains the latest technical information about
 Microsoft language products. For more information about Microsoft
 OnLine, which is designed for software developers, call (800) 443-
 4672. For more information about CompuServe, which is the largest
 general online information service for personal computer users, call
 [phone].

 Sincerely,

 Blain Barton
 Business Languages Team Manager
 Product Support Services
 BP0359

 BP0360: Pascal Question Reply Letter
 ------------------------------------

 Dear PASCAL Customer:

 Thank you for your letter concerning our PASCAL language product.
 Although we are unable to respond to your technical questions by
 letter, we do forward your letters to our PASCAL development team.
 This procedure provides developers with customer feedback, which will
 in turn make Microsoft's products even better. Now that we can no
 longer respond to letters (unless solicited by Microsoft), we are
 providing the following new service:

 Our toll-line number, [phone], is available Monday through
 Friday (except holidays), 8 AM to 5 PM Pacific Standard Time, and is
 designed to answer questions about set up and installation procedures,
 problem reports, and documentation errors. We also address most
 programming, code debugging, and problem solving issues.

 There are many supplemental sources of information relating to the
 PASCAL languages, including reference guides and books published by
 Microsoft Press. Support is also available electronically through
 Microsoft OnLine and CompuServe. One of the features of these services
 is to provide access to the Microsoft Knowledge Base. The Microsoft
 Knowledge Base contains the latest technical information about
 Microsoft language products. For more information about Microsoft
 OnLine, which is designed for software developers, call (800) 443-
 4672. For more information about CompuServe, which is the largest
 general online information service for personal computer users, call
 [phone].

 Sincerely,

 Blain Barton
 Business Languages Team Manager
 Product Support Services
 BP0360

 BP0361: Pascal Problem/Docerr Reply Letter
 ------------------------------------------

 Dear PASCAL Customer:

 Thank you for your letter concerning your problem and/or documentation
 error pertaining to our PASCAL language product. Although we are
 unable to respond to your technical questions by letter, we do forward
 your letters to our PASCAL development team. This procedure provides
 developers with customer feedback, which will in turn make Microsoft's
 products even better. Now that we can no longer respond to letters
 (unless solicited by Microsoft), we are providing the following new
 service:

 Our toll-line number, [phone], is available Monday through
 Friday (except holidays), 8 AM to 5 PM Pacific Standard Time, and is
 designed to answer questions about set up and installation procedures,
 problem reports, and documentation errors. We also address most
 programming, code debugging, and problem solving issues.

 There are many supplemental sources of information relating to the
 PASCAL languages, including reference guides and books published by
 Microsoft Press. Support is also available electronically through
 Microsoft OnLine and CompuServe. One of the features of these services
 is to provide access to the Microsoft Knowledge Base. The Microsoft
 Knowledge Base contains the latest technical information about
 Microsoft language products. For more information about Microsoft
 OnLine, which is designed for software developers, call (800) 443-
 4672. For more information about CompuServe, which is the largest
 general online information service for personal computer users, call
 [phone].

 Sincerely,

 Blain Barton
 Business Languages Team Manager
 Product Support Services
 BP0361


 244. SIZEOF Returns Wrong Value with Multidimensional Super Array

 Product Version(s): 3.32 4.00
 Operating System:   MS-DOS
 Flags: ENDUSER | SR# S901107-110 buglist3.32 buglist4.00
 Last Modified: 10-NOV-1990    ArticleIdent: Q66807

 If a multidimensional super array is declared with different values
 for the lower array bounds, the sizeof() function will return an
 incorrect value for the size of the array. This problem is illustrated
 in the program below.

 Microsoft has confirmed this to be a problem in Microsoft Pascal
 versions 3.32 and 4.00 for MS-DOS. We are researching this problem and
 will post new information here as it becomes available.

 After examining the resulting assembly code using CodeView, it appears
 that the sizeof() function assumes that the base value of both the
 dimensions is the same. For example, if the "sup" type is modified to
 read as follows

      sup = super array[1..*,1..*] of integer;

 this will return the correct answer of 20 bytes for the size.
 Apparently, memory is being referenced and allocated correctly;
 however, the sizeof() function is clearly returning the wrong value in
 the first case.

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

 program sample(input, output);

 type
   sup = super array[1..*,0..*] of integer;

 var
   x : ^sup;
   y : word;

 begin
   new(x, 1, 10);     { 1 integer * 11 integers (0..10) = 11 integers }

   y := sizeof(x^);   { 11 integers * 2 bytes/integer = 22 bytes }
   writeln(y);        { writeln prints 20 }
 end.


 245. Patch for PASCAL.LIB 3.30; DIRECT Access File SEEK/PUT Problem

 Product Version(s): 3.30
 Operating System:   MS-DOS
 Flags: ENDUSER | appnote SP0281 buglist3.30 fixlist4.00
 Last Modified: 14-DEC-1990    ArticleIdent: Q67000

 The application note "Patch for PASCAL.LIB 3.30" is available from
 Microsoft Product Support Services.

 This application note corrects a problem with DIRECT file access in
 Microsoft Pascal version 3.30. Microsoft has confirmed this to be a
 problem in Microsoft Pascal Compiler version 3.30 for MS-DOS. (This
 problem was corrected in Microsoft Pascal Compiler version 4.00;
 therefore, owners of Pascal version 4.00 do not need this application
 note.)

 This application note includes the following four files:

 1. PASNEW.LIB replaces the PASCAL.LIB shipped with Pascal 3.30. You
    can rename PASNEW.LIB to PASCAL.LIB to replace the old PASCAL.LIB,
    or you can specify PASNEW.LIB at the library (.LIB) prompt at link
    time. Make sure to keep the original 3.30 PASCAL.LIB as an archive.

 2. FILF.OBJ is a corrected version of the module that is incorrect in
    the old PASCAL.LIB library. Specifying FILF.OBJ at the object
    module (.OBJ) prompt at link time will also implement the patch
    without using the PASNEW.LIB library.

 3. DIRECT.PAS is a code example that shows the DIRECT file access
    problem.

 4. READ.ME is a copy of the text of this application note.

 The following steps (shown in the DIRECT.PAS example on the enclosed
 disk) demonstrate the problem with DIRECT file access in Pascal 3.30:

 1. Open a file with DIRECT access and write to it.

 2. Close the file and open it again.

 3. SEEK to one of the records you previously wrote.

 4. Attempt to PUT a new value in the record and close the file again.

 The above steps cause the new value to not be placed in the record.
 Also, the directory length of the file may be incorrect. The
 PASNEW.LIB and FILF.OBJ files on the enclosed disk correct this
 problem.

 Code Example (DIRECT.PAS)
 -------------------------

 Program test(INPUT,OUTPUT);

 Var
     f: file of word;
     i: integer;
     J:INTEGER;

 Begin
     WRITE('ENTER NUMBER OF RECORDS ');
     READLN(J);
     assign(f, 'testfile');
     f.mode:=direct;
     f.share:=sm_denyrd;
     rewrite(f);
     f^:=0;                          { fill value    }
     FOR I:=1 TO J DO PUT(F);          {J RECORDS GET FILLED WITH 0}
     close(f);

     WRITE('ENTER RECORD NUMBER TO SEEK ');
     READLN(J);
     RESET(F);
     SEEK(F,J);
     f^:=1;                          { put a 1 in the buffer }
     put(f);                         { write it }
     close(f);

     RESET(F);
     SEEK(F,J);
     GET(F);
     WRITELN;
     WRITELN('F^=',F^:2,'       F^ SHOULD EQUAL 1');
     CLOSE(F);
 End.


 246. Incorrect Reference of ADSMEM EXTERN FUNCTION; Pascal Example

 Product Version(s): 4.00   | 4.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | SR# S901116-96 buglist4.00
 Last Modified: 26-DEC-1990    ArticleIdent: Q67375

 The PASCAL compiler fails to flag an incorrect usage of a FUNCTION
 that returns an ADSMEM value.

 Microsoft has confirmed this to be a problem with the Microsoft Pascal
 Compiler version 4.00 for MS-DOS and MS OS/2. To work around the
 problem, learn and use the correct syntax.

 The code below shows both the correct syntax and the illegal syntax of
 the use of a FUNCTION that returns an ADSMEM value. The correct logic
 is to assign the value returned by the FUNCTION to an ADSMEM variable,
 then reference the desired part of the ADSMEM variable.

 PROGRAM test1(output,input);

 var
    a: WORD;
    b: ADSMEM;

 FUNCTION Getmqq: ADSMEM; EXTERN;

 ! Program to display how to reference the correct offset of a
 ! memory address.

 BEGIN
    a := Getmqq.r;                  !wrong assignment statement
    WRITELN (output,'a.r = ',a.r);  !wrong result
    b := Getmqq;                    !correct assignment
    WRITELN (output,'b.r = ',b.r);  !correct results
 END.


 247. Pascal 4.00 Manual Incorrectly Refers to SORT.PAS File

 Product Version(s): 4.00   | 4.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | docerr
 Last Modified: 26-DEC-1990    ArticleIdent: Q67376

 Pages 22 to 31 of the "Microsoft Pascal Compiler: User's Guide" for
 Pascal 4.00 incorrectly make reference to the program, SORT.PAS. In
 this section of the manual, SORT.PAS serves as a sample program for
 demonstrating the use of the PASx compile and LINK commands from DOS.
 Attempting to follow the examples in this part of the manual using
 Pascal 4.00 will fail because SORT.PAS was not shipped with Pascal
 version 4.00. It was only shipped with Pascal version 3.32.

 The reference to SORT.PAS on pages 22 to 31 should be changed to a
 different demo program, such as SORTDEMO.PAS. SORTDEMO.PAS can be used
 in place of SORT.PAS for the purpose of demonstrating the compile and
 link commands from DOS.

 This information applies to Microsoft Pascal version 4.00 for MS-DOS
 and MS OS/2.

 Note that SORTDEMO.PAS and SORT.PAS are not the same program.
 SORTDEMO.PAS contains many sorting algorithms, such as bubble sort,
 quick sort, insertion sort, and so on. SORT.PAS just contains a simple
 bubble sort algorithm.

 If Pascal 4.00 is configured to run only under DOS (and not OS/2) on
 your system, you will need to copy the file OS2.INT from the Examples
 disk to the INCLUDE path of your hard drive. The PAS1 compiler will
 need to open this file when compiling SORTDEMO from DOS. Absence of
 this file will result in the error "File access error ... " at compile
 time. For more information on this problem, query on the following
 words:

    Pascal and sortdemo and bound


 248. "Symbol Defined More Than Once: SUBSQQ" Error

 Product Version(s): 3.04
 Operating System:   MS-DOS
 Flags: ENDUSER | TAR56929
 Last Modified:  2-JAN-1991    ArticleIdent: Q11985

 Question:

 While adding a Pascal language-user interface to our FORTRAN language
 system, a run-time library compatibility problem has surfaced. When we
 search both run-time libraries during a link, a "Symbol defined more
 than once: SUBSQQ" error is reported in the second run-time library
 searched.

 This is both an operational problem (our MAKEs terminate at the error)
 and a potential run-time problem. The only run-time problem we know of
 occurs when the FORTRAN substring is used (for example, TEST(I:I)=' ')
 and the Pascal library is searched first. This problem will generally
 lock up a system at run time.

 We would like to know the following:

 1. Is there a patch for the libraries?

 2. Is there a potential Pascal run-time problem when we link the
    FORTRAN library first to solve the FORTRAN substring crash?

 Response:

 No. You are not likely to have a problem using the executable you
 created.

 For the first problem with the MAKE file, you should use conditional
 execution based on whether or not you receive certain error levels.

 In regard to the library problem, you may have a FORTRAN main program
 that calls Pascal routines that, for example, provide a user interface
 to your system. However, there may be something in the structure of
 your program that tangles the linker.

 Examine the contents of the FORTRAN and Pascal libraries using the LIB
 utility. You can see that the function SUBSQQ is present in both
 PASCAL.LIB and FORTRAN.LIB. You also can see that the object module
 contains the SUBSQQ function in the Pascal library, which contains
 many other entry points. This is in contrast to the FORTRAN object
 module containing SUBSQQ, which only has three entry points. The
 following is an example:

 PASCAL.LIB:
 ----------

 sets              Offset: 000101d0H  Code and data size: 4c5H
   ADDSQQ            CEQSQQ            CLESQQ            CLTSQQ
   MIN               MULSQQ            O3ESQQ            SETSQQ
  *SUBSQQ*           T3OSQQ            Z3RSQQ

 FORTRAN.LIB:
 -----------

 fstl              Offset: 0000fb00H  Code and data size: 19eH
   FCPSQQ            FSTLQQ            SUBSQQ

 An entry point is not necessarily a function. For example, in the
 FORTRAN library module containing SUBSQQ, FCPSQQ is actually a module
 name, while SUBSQQ is a procedure and FSTLQQ a function.

 Your program uses at least one entry point contained in both of these
 two modules. The entry point does not necessarily need to be SUBSQQ.

 For example, if you first link in the Pascal library and then the
 FORTRAN library (and if your program generates calls to ADDSQQ and
 FSTLQQ), the linker will first pull in the "sets" module from the
 PASCAL.LIB to resolve the reference to ADDSQQ. The linker then must
 pull in the "fstl" module from the FORTRAN.LIB to resolve the
 reference to FSTLQQ. The linker will then check all its entry points
 for duplicates, find that now it has duplicates of the SUBSQQ
 procedure, and generate a message that you have pulled in two
 (possibly different) versions of SUBSQQ.

 This procedure should generate a fatal error and make it impossible
 for you to proceed. If this occurs and your machine hangs, try
 switching your link order. Everything should work properly because you
 are using two Microsoft compilers, as well as using the same version
 number of two particularly compatible compilers (they share the same
 source code for many routines). In fact, the SUBSQQ procedure is
 indeed identical in FORTRAN and Pascal version 3.31.

 We recommend that you proceed with the executable you created by
 linking in FORTRAN first, then Pascal. You should not encounter any
 problems using this procedure.


 249. ADS of Function/Procedure May Gives Incorrect Results

 Product Version(s): 4.00   | 4.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | SR# S901116-69
 Last Modified:  2-JAN-1991    ArticleIdent: Q67888

 ADS returns the segment and offset of a variable, function, or
 procedure. When calling ADS of a intrinsic function, it will return
 the incorrect address of zero. ADS of an external function/procedure
 will produce the correct results unless an ADS call to an intrinsic
 was performed first. In the latter case, it will then assign zero to
 the variable of the ADS of the external function/procedure and assign
 the ADS of the external function/procedure to the variable that holds
 the ADS of the intrinsic function/procedure.

 This information applies to Microsoft Pascal version 4.00 for MS-DOS
 and MS OS/2.

 In the code example below, the wrong addresses are printed. If Getmmq
 had been the only use of the ADS function, the correct results would
 have be printed. With the second use of the ADS function on the
 external, the addresses are incorrectly switched and the ADS of F1
 procedure prints the address of Getmmq, and the ADS of Getmmq function
 prints zero. Had the ADS of the intrinsic function been the only call,
 then ADS would have returned zero.

 PROGRAM t(output,input);
 VAR
    a,b: ADSMEM;

 FUNCTION F1:INTEGER;
 BEGIN
    F1 := 5;
 END;

 FUNCTION Getmqq(wants : WORD):ADSMEM;EXTERN;

 BEGIN
   a := ADS F1;
   b := ADS Getmmq;
   WRITELN(output,'F1    =',RETYPE(INTEGER4,b)); !prints ADS of GETMQQ
   WRITELN(output,'GETMQQ=',retype(INTEGER4,a)); !prints "0"
 END.


 250. PASCAL 4.0 Can Fail to Report Bad RETYPE Arguments; Cause Hang

 Product Version(s): 4.00   | 4.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | SR# S901220-19
 Last Modified:  9-JAN-1991    ArticleIdent: Q68022

 The Pascal compiler does not always detect errors in the arguments of
 the RETYPE function, which can cause the program to hang at run time.

 Microsoft has confirmed this to be a problem with Microsoft Pascal
 Compiler version 4.00 (buglist4.00). We are researching this problem
 and will post more information here as it becomes available. To work
 around the problem, pass the correct arguments to the RETYPE function.

 The RETYPE function takes two arguments: the first argument is the
 type; the second argument is a declared variable. The RETYPE command
 will type-cast the second argument using the first argument. In the
 code below, the compiler does not detect an error. When the program
 below is run, the computer will hang.

 program test(output,input);
 type
    t = ads of integer;   !segment address of integer
 var
    a : ads of word;      !segment address of word

 procedure p(const x: integer4);
    begin writeln('X = ',x); end;

 begin
    p(retype (t,a)^);                  ! correct code
    p(retype (t, ads a^)^);            ! incorrect code..
 end.                                  ! ..convert the address of
                                       ! ..pointer into a type???

 The compiler should detect this error on the first pass and generate
 the "^201 Types Not Assignment Compatible" error on the second call to
 procedure p.


 251. Summary of Pascal 4.00 Compiler's Command-Line Switches

 Product Version(s): 4.00
 Operating System:   MS-DOS
 Flags: ENDUSER | SR# S910201-74
 Last Modified: 14-FEB-1991    ArticleIdent: Q69175

 The following is a summary of the command-line switches for Microsoft
 Pascal Compiler version 4.00. All switches correspond to Pascal
 metacommands, so you can either use the metacommand in the source file
 or give the command as a switch to the compiler. Any instruction given
 as a metacommand in the source file overrides the corresponding switch
 given at compile time.

 For more information about the compiler and its switches, see Chapter
 5, "More About Compiling" in the "Microsoft Pascal Compiler for MS-DOS
 Operating System: User's Guide" for version 4.00.

    Switch     Default     Metacommand     Action
    ------     -------     -----------     ------

    /A         Off         $indexck        Checks for array index values
                                           in range, including super
                                           array indices.

    /C         Off         $decmath        Directs the compiler to use
                                           the decimal math routines in
                                           the math run-time library,
                                           DECMATH.LIB.

    /D         Off         $debug          Switches on all debugging
                                           switches.

    /E         Off         $entry          Generates procedure entry and
                                           exit calls for the debugger.

    /I         Off         $initck         Checks for use of
                                           uninitialized values.

    /L         Off         $line           Generates line-number calls
                                           for debugger.

    /M         Off         $mathck         Checks for mathematical errors,
                                           such as overflow and division
                                           by zero.

    /N         Off         $nilck          Checks for dereferencing of
                                           any pointers that are NIL.

    /Q         Off         $debug          Switches off all debugging
                                           switches.

    /R         Off         $rangeck        Checks for subrange validity
                                           including assignments.

    /S         Off         $stackck        Checks for stack overflow at
                                           procedure or function entry.

    /T         Off         $tagck          Checks tag fields in variant
                                           records.

 The debug (/D) switch will turn on all debug switches (those whose
 metacommand ends with "CK"). The error-checking switches and
 corresponding metacommands cause a significant increase in the size of
 code generated. Therefore, you may want to use them in the early
 stages of program development, then recompile your program without
 them once you have thoroughly debugged your program (for example, use
 the /Q switch to turn off debug switches). Removing the debug switches
 will reduce your program's code size.






 Microsoft QuickPASCAL Compiler
 =============================================================================


 1. QuickPascal Does Not Support Installable Graphics Drivers

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified:  3-MAY-1989    ArticleIdent: Q43769

 Turbo Pascal has a routine called InstallUserDriver to install a
 vendor-added graphics device driver. QuickPascal Version 1.00 does not
 implement installable graphics device drivers.

 At this point, we know of no programs that have been written that have
 implemented this call because no one has developed these vendor-added
 graphics device drivers.


 2. QuickPascal Does Not Link TPUs

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified:  3-MAY-1989    ArticleIdent: Q43770

 A file with an extension of .TPU is a precompiled unit file used in
 Turbo Pascal. QuickPascal Version 1.00 does not link Turbo Pascal .TPU
 files. If the source code for .TPU files is available, compile it using
 QuickPascal. This will create a .QPU file (QuickPascal unit file),
 which then can be used by QuickPascal.


 3. QuickPascal Not Compatible with Turbo Pascal 3.0

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified:  3-MAY-1989    ArticleIdent: Q43771

 Microsoft QuickPascal Version 1.00 is not compatible with Turbo Pascal
 Version 3.0. It is source compatible with Turbo Pascal 5.0.

 The Turbo Pascal 5.0 package includes TURBO3.TPU and GRAPH3.TPU units
 to make Turbo Pascal 5.0 compatible with Version 3.0.

 The units equivalent to TURBO3.TPU and GRAPH3.TPU are not included in
 QuickPascal Version 1.00.


 4. Description of units and their use

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified:  3-MAY-1989    ArticleIdent: Q43970

 Question:

 How do I implement the idea of modules in QuickPascal?

 Response:

 To use modules in QuickPascal you must create a "unit."  A unit is
 a collection of constants, data types, variables, procedures, and
 functions.

 To create a unit, do the following:

 1. Create a program (call it MODULE1.PAS, for example) that adheres to
    the unit specification. More information on unit specification is
    given below.

 2. Compile MODULE1.PAS. QuickPascal produces a file by the name of
    MODULE1.QPU. MODULE1.QPU is a unit.

 In the main program, include the line after the program statement:

    uses module1;

 The module1 unit is now automatically "linked" with the main program.

 A unit starts with the reserved word UNIT, followed by the unit's name.
 The unit also contains INTERFACE and IMPLEMENTATION sections. The
 INTERFACE section is "visible" to any other units or programs that use
 this unit. The IMPLEMENTATION section is not "visible" to any programs
 that use this unit. The IMPLEMENTATION section usually is used by
 "visible" procedures and functions that appear in the INTERFACE
 section.

 See also "Pascal By Example," Chapter 7, Pages 87-93.


 5. QuickPascal Accepts a Function Name as an Argument

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 19-MAY-1989    ArticleIdent: Q44473

 The Microsoft QuickPascal Compiler Version 1.00 accepts a function
 name as an argument to a procedure as shown below; however, Turbo
 Pascal Version 5.00 does not accept it.

 Turbo Pascal Version 5.00 thinks that the Foo is a recursive call when
 it is specified in the Val procedure. In QuickPascal, this is a way to
 assign a value to the Foo function. No recursion is performed.

 function Foo(Var.....) : REAL;

 begin
    .
    .
    Val(Mystring,Foo,Error);
 end;


 6. Example of QuickPascal to Assembler Procedure Call

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified:  6-SEP-1989    ArticleIdent: Q44474

 QuickPascal Version 1.00 can interface to assembler object modules.
 The following example shows how to access global variables from within
 the assembly routine; it also shows the segment conventions necessary
 to interface with QuickPascal:

 Program PasAsmTest;
 {$F+}                               (* Turn on far call model *)
 {$L AsmTest}                        (* Turn on local symbol info *)
 Procedure TestRoutine;  External;   (* Define routine as external *)
 {$F-}                               (* Turn off far call model *)
 VAR
    TestInt : Integer;
    TestBool: Boolean;

 BEGIN
    TestInt := 2;
    TestBool := FALSE;
    Writeln ('Before assembly call, variables are:');
    Writeln ('TestBool = ', TestBool);
    Writeln ('TestInt = ', TestInt);
    TestRoutine;
    Writeln;
    Writeln ('After assembly call, variables have changed');
    Writeln ('TestBool now equals ', TestBool);
    Writeln ('TestInt = ', TestInt);
 END.

 ; Assemble command lines
 ;
 ; MASM:
 ;     Assemble with:
 ;            Masm asmtest.asm;
 ;
 ; QuickAssembler command line:
 ;     Assemble with:
 ;            qcl /c asmtest.asm
 ;
 ; QuickAssembler environment:
 ;     Choose Options.Make.Build Flags, Release mode (not Debug)
 ;     Choose Options.Make.Assembly Flags.Labels, Convert to Upper

 DATA Segment
    TRUE  Equ  1
    Extrn TestBool : BYTE
    Extrn TestInt  : WORD
 DATA Ends

 CODE Segment                  ; Setup Code and Data segments
    ASSUME CS:CODE,DS:DATA

 Public TestRoutine
 TestRoutine Proc Far
    PUSH     BP
    MOV      BP, SP            ; Preserve required registers on stack
    PUSH     DS

    Mov      TestBool, TRUE    ; Change the variables
    Mov      TestInt, 0010

    POP      DS
    MOV      SP, BP            ; Restore to entry state
    POP      BP
    RET
 TestRoutine EndP
 CODE EndS
 END

 Please note the following standard conventions:

 1. All code is placed within a single segment called Code.

 2. Data cannot be declared within the assembly routine.

 3. The BP, SP, and DS are preserved. DS and SS need only be preserved,
    if used. The above example uses the standard entry and exit form
    for Microsoft interfacing.


 7. QuickPascal Fillmasks Are Transparent

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 25-MAY-1989    ArticleIdent: Q44476

 Question:

 Turbo Pascal Version 5.00 fillmasks are opaque. Does QuickPascal
 follow this convention?

 Response:

 No, it does not. QuickPascal fillmasks are transparent; however, there
 are differences in how fillmasks are handled by different
 figure-drawing functions.

 If you use a _rectangle function and fill the rectangle with a
 pattern1, then draw an overlapping second rectangle and fill that with
 a pattern2, you will see both patterns in the overlay area. In Turbo
 Pascal 5.00, you will only see pattern2 in the overlay area.

 The _ellipse and _pie functions use a different fill algorithm
 (floodfill). Thus, if you fill an overlapping ellipse (or pie) it does
 not fill the entire area; it fills until it hits a solid border.
 Depending on where the center of the ellipse (or pie) is, either the
 overlap area or the nonoverlap area is filled; not both. In the case
 of the overlap area being filled, you see both patterns.

 The following program draws two overlapping rectangles and two
 overlapping ellipses with different centers and fills them with
 different patterns:

 program fill (input, output);

 uses MsGraph, Crt;

 CONST
    mask1 : _FillMask = (0,66,36,24,0,0,0,0);
    mask2 : _FillMask = (0,0,0,0,24,36,66,0);

 VAR
    errorcode : INTEGER;
    c         : CHAR;

 BEGIN
    errorcode := _setvideomode(_MRES16COLOR);

    _setcolor(3);
    _setfillmask (mask1);
    _ellipse (_GFILLINTERIOR,100,40,160,170);
    _ellipse (_GFILLINTERIOR,210,40,280,140);
    _rectangle (_GFILLINTERIOR,0,20,60,80);

    _setfillmask (mask2);
    _rectangle (_GFILLINTERIOR,20,40, 80,130);
    _ellipse (_GFILLINTERIOR,110,40,200,180);
    _ellipse (_GFILLINTERIOR,260,40,310,200);

    c := ReadKey;
    errorcode := _setvideomode(_DEFAULTMODE);
 END.


 8. Misleading Error Message in QuickPascal Debug Window

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist1.00
 Last Modified: 26-SEP-1989    ArticleIdent: Q44708

 If a numeric value followed by a letter is entered in the QuickPascal
 Debug window, the error message "<Error P0008: Invalid end of line>"
 is displayed. This is misleading. A more accurate error message is
 "Invalid expression."

 An example of when this error message appears is if you mistyped the
 command "32,h" (which is used to print the hexadecimal equivalent of
 32). The misleading error message will be reported if the command is
 entered as "32h".

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


 9. Byte Used as Parameter Generates Invalid Error Message

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist1.00
 Last Modified: 31-MAY-1989    ArticleIdent: Q44709

 The following program produces "Error 127: Invalid variable reference"
 when compiled with QuickPascal 1.00. The error message is incorrect
 because the syntax for the code is correct.

 PROCEDURE Broken (VAR b : Byte);
 BEGIN
 END;

 VAR
     x : Boolean;

 BEGIN
    Broken ( Byte(x) );
 END.

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

 To work around the problem, use a temporary variable as the parameter
 passed to Broken, as follows:

 PROCEDURE Broken (VAR b : BYTE);
 BEGIN
 END;

 VAR
     x    : BOOLEAN;
     temp : BYTE;

 BEGIN
    temp := Byte (x);
    Broken ( temp );
 END.


 10. QP Cannot Compare Packed Arrays of Char > 255 Elements

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | docerr
 Last Modified: 31-MAY-1989    ArticleIdent: Q44710

 QuickPascal generates "Error 51: Conflicting operands" when packed
 arrays of characters greater than 255 elements are compared.

 Turbo Pascal has the same limitation. Packed arrays of characters with
 more than 255 elements are not supported in QuickPascal. The on-line
 help should mention this, but does not.

 The following program demonstrates the problem:

 CONST
    max = 256;

 VAR
    s1,
    s2  : PACKED ARRAY [1..max] OF CHAR;
    i   : INTEGER;

 BEGIN
     FOR i := 1 TO max DO
       BEGIN
           s1[i] := ' ';
           s2[i] := ' ';
       END;

     IF s1=s2
        THEN Writeln ('PASS')
        ELSE Writeln ('FAIL');
 END.


 11. Documentation Error in QuickPascal README.DOC: QPENV.ENV

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | docerr
 Last Modified: 21-JUN-1989    ArticleIdent: Q45488

 The README.DOC file from the Setup/Utilities disk of QuickPascal
 Version 1.00 incorrectly states that information regarding the QP
 environment is found in the file titled QPENV.ENV. Information on the
 environment is actually found in the help file named QPENV.HLP.


 12. _GrStatus Is Documented in the On-line Help Only

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 21-JUN-1989    ArticleIdent: Q45489

 QuickPascal contains the MSGraph function _GrStatus, which returns the
 status of the most recently executed graphics routine. _GrStatus
 checks for errors that can occur when executing graphics routines.

 _GrStatus is not covered in "Pascal by Example," but it is completely
 documented in the on-line help system.

 See the on-line help system program, PALETTE1, for an example of how
 to use _GrStatus.


 13. QuickPascal Will Hang above 173 Levels of Nested Procedures

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist1.00
 Last Modified: 21-JUN-1989    ArticleIdent: Q45491

 In the Pascal language, procedures may be defined within other
 procedures. If you nest too many procedures, QuickPascal (and QPL)
 will hang. The procedures can be nested up to 127 levels with
 QuickPascal and Turbo Pascal. Above 127 levels, Turbo Pascal generates
 the error "Too many nested scopes"; above 128 levels, QuickPascal
 generates the error "Unknown identifier (P128)." However, above 173
 levels of nesting, QuickPascal will hang.

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


 14. QuickPascal Supports Arrays Up to Limit of DOS

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 21-JUN-1989    ArticleIdent: Q45492

 QuickPascal supports static and dynamic allocation of arrays up to 64K
 in length. When using getmem() to allocate an array dynamically, you
 may allocate from 0 to 65519 bytes. The static allocation limit is
 restricted by a total data segment size of 64K. All other static data
 and start-up and run-time overhead also come out of this 64K.

 If you would like to allocate data items larger than this amount, you
 must use BIGHEAP.QPU, which is a unit provided to do so. The sample
 program BIGMEM.PAS gives an example of how to do this. BIGHEAP.QPU
 allows allocations up to the amount of free memory under DOS.


 15. Latest Logitech Mouse Driver Works Fine with QuickPascal

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 23-JUN-1989    ArticleIdent: Q45636

 There were some problems with early Logitech mouse drivers and
 QuickPascal 1.00. Two of the problems are as follows:

 1. When QuickPascal was in 43-line mode, the mouse would not go below
    line 25.

 2. The mouse cursor appeared to split into two pieces so it appeared
    as if you had two cursors.

 All known problems with Logitech Mice and QuickPascal Version 1.00 are
 solved by obtaining the latest mouse driver (Version 4.00) from
 Logitech. You can call Logitech at [phone].


 16. Type with STRING Can Hang QP.EXE If Tracing (F8) Through Code

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | SR# S910111-255 buglist1.00
 Last Modified:  6-FEB-1991    ArticleIdent: Q68662

 An assignment to the second string variable within a record type will
 hang the machine if you try to Trace (F8) through the source code in
 the QP.EXE environment. This problem will occur when you try to step
 through any statement after the string assignment.

 Microsoft has confirmed this to be a problem in Microsoft QuickPascal
 version 1.00 for MS-DOS. We are researching this problem and will post
 new information here as it becomes available.

 The program will execute correctly as an executable .EXE file.

 The following code will hang the machine after the assignment of
 F^.Str2 when using the Trace (F8) command in QP.EXE. To duplicate the
 problem, the second variable within the record must be a string. The
 length of the string does not matter. The program will hang if you
 Trace (F8) though the code and then try to step through any statement
 after the string assignment.

 Sample Code
 -----------

 program test;
 uses DOS;
 type
    FCB = record
       Str1 : integer;         {anything}
       Str2 : string[3];       {has to be a string}
    end;
 var
    F : ^FCB;

 begin
    F^.Str1 := 34;
    F^.Str2 := '34';           {step through and hangs}
 end.


 17. QP 1.00 README: Special Instructions for QuickPascal Express

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 27-JUN-1989    ArticleIdent: Q45968

 The following information is taken from the QuickPascal Version 1.00
 README.DOC file.

 Special Instructions for QP Express
 -----------------------------------

 You may have difficulty running the QP Express Computer-Based Training
 (CBT) program due to your video driver/graphics card combination. Try
 the following:

 1. Make a backup copy of the QP Express or QP Express/QP Advisor disk.
    Use the backup copy for the remainder of this procedure.

 2. On the backup copy of the QP Express or QP Express/QP Advisor disk,
    you will find files with the extension .VID. Each of these files is
    a driver for a specific type of graphics card. The following
    drivers support the indicated graphics cards:

       Driver            Graphics Cards
       ------            --------------

       ATT6300.VID       For Olivetti and ATT PCs
       CGASNO.VID        For CGA cards that produce a snow effect
       ERICSSON.VID      For Ericsson PCs
       HERC102.VID       For the Hercules 102 card
       HERC112.VID       For the Hercules 112 card

    If you use one of these computers/displays, rename the appropriate
    driver to SCREEN.VID. For example, if you run an AT&T computer,
    type the following:

       RENAME ATT6300.VID SCREEN.VID

 3. You can now resume SETUP or run the CBT directly by typing LEARN.


 18. QuickPascal Data Type Byte Is Unsigned Not Signed

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | docerr
 Last Modified: 23-JUN-1989    ArticleIdent: Q45970

 The documentation "Pascal by Example" incorrectly states that data
 type Byte is a signed byte (value range from -128 to 127) on Page 156.

 The documentation correctly states that data type Byte is an unsigned
 byte (value range from 0 to 255) on Page 14. Data type Byte is also
 correctly identified as an unsigned byte in the QuickPascal Advisor
 (on-line help) under "Pascal Language, Data Types."


 19. All Objects Must Be Defined Before Methods Can Be Written

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified:  6-SEP-1989    ArticleIdent: Q46008

 When creating a QuickPascal program involving object-oriented
 programming (OOP), you must define all objects before writing the
 methods associated with these objects. It may seem natural to define
 an object, the methods associated with it, and then the next object;
 however, this is not the proper way to write QuickPascal OOP code.

 You get the following error:

    Source: C:\Workdir\file.pas
    Error 21: BEGIN expected

 Instead, you must define all of your objects first, and then define
 all of their methods.

 Incorrect Coding
 ----------------

 PROGRAM test;

 Type
    Texperiment1 = OBJECT
       ch1 : char;
       PROCEDURE exp_method1;
    End;
    PROCEDURE Texperiment1.exp_method1;
    Begin
      { Method code }
    End;

    Texperiment2 = OBJECT
       ch2 : char;
       PROCEDURE exp_method2;
    End;
    PROCEDURE Texperiment2.exp_method2;
    Begin
      { Method code }
    End;

 BEGIN    { Main Code }
 END.     { End of main }

 Correct Coding
 --------------

 PROGRAM test;

 Type
 { Define Objects }
    Texperiment1 = OBJECT
       ch1 : char;
       PROCEDURE exp_method1;
    End;

    Texperiment2 = OBJECT
       ch2 : char;
       PROCEDURE exp_method2;
    End;

 { Define Methods }
    PROCEDURE Texperiment1.exp_method1;
    Begin
      { Method code }
    End;
    PROCEDURE Texperiment2.exp_method2;
    Begin
      { Method code }
    End;

 BEGIN    { Main Code }
 END.     { End of main }


 20. QuickPascal Allows Redirection at the DOS Prompt

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 27-JUN-1989    ArticleIdent: Q46132

 DOS redirection allows you to specify both input and output files for
 Microsoft QuickPascal programs. In programs that do not use the Crt
 unit, all that is required is to issue the following command line:

    programname <inputfile >outputfile

 If the program uses the Crt unit, the command line above must be used,
 and in addition, the following four lines must be included in the file
 prior to the first input or output statement:

    Assign( Input, '' );
    Reset( Input, '' );
    Assign( Output, '' );
    Reset( Output, '' );

 The above four lines are required because the Crt unit changes the
 names of the standard input and output sources; the four lines above
 reassign them to their original settings. This change is made to speed
 up the I/O operations. Programs that do not use the Crt unit send the
 output to the screen through DOS, which adds overhead. Programs that
 use the Crt unit can send the output directly to the BIOS or directly
 to video memory.

 Borland's Turbo Pascal operates the same way. If you want to redirect
 the I/O and use the Crt unit, you must include the same four lines of
 code.

 More information on I/O redirection can be found in the "Microsoft
 QuickPascal Pascal by Example" manual on Page 104. More information on
 the Crt unit can be found in the same manual starting on Page 105.


 21. No Purple-Labeled Disks in QuickPascal Version 1.00

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | docerr
 Last Modified: 13-JUL-1989    ArticleIdent: Q46451

 Problem:

 On Pages 4 and 5 of the "Microsoft QuickPascal Up and Running" manual,
 the following instructions are given:

    Insert the purple-labeled Setup/Utilities distribution disk.

 I don't have any purple-labeled disks.

 Response:

 This is a documentation error. There are no purple-labeled disks with
 Microsoft QuickPascal Version 1.00. All disks, including the
 Setup/Utilities disk, are white, blue, and tan.


 22. Auto Recompile and Debug option

 Product Version(s): 1.00   | 1.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified: 13-JUL-1989    ArticleIdent: Q46730

 When you turn the "debug information" option Off in the compile
 options window, the compiler does not recompile when you use F5 to run
 after a change was made in the source.

 When you load a file into QuickPascal (QP) and press F5 to run it, QP
 compiles and runs the program. If you quit the program and go back to
 the source, change the source, and press F5 to run again, QP
 recompiles (because the source was changed) and runs just as expected.

 However, if you turn debug information Off and press F5 to run, QP
 recompiles the program as expected (because a change was made to the
 environment). If you quit the program and return to the source, change
 the source, and press F5 to run again, QP does not recompile here when
 it should because the source has been changed.

 With the debug information option Off, you must use the "build main
 program" option under the Make menu to get the program recompiled.

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


 23. QuickPascal Editor Cannot Mark Last Line of File

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist1.00
 Last Modified: 13-JUL-1989    ArticleIdent: Q46742

 QuickPascal does not mark (SHIFT+DOWN ARROW) the last line in a file
 unless the line is followed by a linefeed character. To get around
 this problem, you should insert a linefeed or use SHIFT+RIGHT ARROW to
 mark the last line.

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


 24. Cannot Get Context-Sensitive Help on Errors in Debug Window

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist1.00
 Last Modified: 13-JUL-1989    ArticleIdent: Q46743

 If you receive an error while in the debug window, you cannot use the
 on-line help system to get help information. This is a limitation of
 QuickPascal Version 1.00.

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


 25. Undocumented Procedures: _Polygon and _Plygon_wxy

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 13-JUL-1989    ArticleIdent: Q46744

 The following two procedures are included in the graphics unit
 MSGraph, but are not included in the documentation:

    PROCEDURE _Polygon( control  : Integer; VAR pointarray;
                        numpoints: Integer );

    PROCEDURE _Polygon_wxy( control   : Integer; Var pointarray;
                            numpoints : Integer);

 Both procedures draw a polygon in the current color. They either draw
 just the outline of the shape or fill the entire shape depending on
 the value of control, either _GBorder or _GFillInterior. The variable
 pointarray is an array of _XYCoords (or _WXYCoords for _Polygon_wxy),
 each of which specifies one of the polygon's vertices. The argument
 numpoints indicates the number of elements in pointarray (the number
 of vertices).

 Neither of these procedures is documented in "Pascal by Example" or in
 the on-line help system. They are documented within the on-line
 README.DOC file.


 26. QuickPascal 1.00 PACKING.LST

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 24-OCT-1989    ArticleIdent: Q46746

 Packing List for Microsoft QuickPascal (R) Compiler, Version 1.00
 5.25-inch disk set is as follows:

 Disk 1: Setup/Utilities

    Files                  Description
    -----                  -----------

 PACKING.LST            Packing list (this file).
 SETUP.EXE              SETUP program -- installs QuickPascal.
 README.DOC             Directs you to README in Help.
 FIXSHIFT.COM           Fixes BIOS bug for certain Compaq and other
                        keyboards.
 MOUSE.COM              Microsoft Mouse driver.
 MSHERC.COM             TSR -- supports Hercules (R) card graphics.
 QPMKKEY.EXE            Creates customized keyboard command files.
 SAMPLES\BIGHEAP.PAS    New versions of GetMem and FreeMem that allocate
                        heap space in blocks larger than 65520 bytes.
 SAMPLES\BIGMEM.PAS     BIGMEM.PAS uses the sample BigHeap unit.
 SAMPLES\MOUSE.PAS      Real mode mouse control routines; derived from
                        Microsoft OS/2 programmer's reference, Chapter 3.
 SAMPLES\SORTDEMO.PAS   Demonstrates six common sorting algorithms.
 SAMPLES\OBJECTS.PAS    Object-oriented demo.
 SAMPLES\CRLF.PAS       Normalizes all line endings of a text file to CRLF.
 SAMPLES\GRDMEO.PAS     Demonstrates the QuickPascal graphics library. It
                        uses two additional units: menu and turtle.
 SAMPLES\MENU.PAS       Used by Grdemo.
 SAMPLES\TURTLE         Used by Grdemo (for Turtle graphics).
 BRIEF.KEY              Keyboard MAP files.
 EMACS.KEY                " "
 EPSILON.KEY              " "
 QP.KEY                   " "
 ME.KEY                   " "

 Disk 2 : Program

    Files                  Description
    -----                  -----------

 QP.EXE                 Microsoft QuickPascal program environment.
 QPL.COM                QuickPascal command-line compiler.
 QPL.ERR                QuickPascal compiler error messages.

 Disk 3: Microsoft QuickPascal Advisor

    Files                  Description
    -----                  -----------

 QP.HLP                 QuickPascal help files.
 QPENV.HLP                " "

 Disk 4: Libraries

    Files                  Description
    -----                  -----------

 SYSTEM.QPU             System Unit.
 CRT.QPU                CRT Interface Unit.
 DOS.QPU                DOS Interface Unit.
 MSGRAPH.QPU            Graphics Interface Unit.
 MSGRUTIL.QPU           Graphics Support Unit.
 GRAPH.QPU              Graphics Support Unit.
 PRINTER.QPU            Printer Interface Unit.
 COURB.FON              Font files.
 ROMAN.FON                " "
 SCRIPT.FON               " "
 TMSRB.FON                " "
 HELVB.FON                " "
 MODERN.FON               " "

 Disk 5: Microsoft QuickPascal Express

    Files                  Description
    -----                  -----------

 LEARN.EXE              Computer-Based Training file.
 QPCBT.CTX                " "
 QPCBT.SCN                " "
 QPCBT.SOB                " "
 LEARN.PIF              Computer-Based Training Windows PIF file.
 ATT6300.VID            Computer-Based Training display drivers.
 CGASNOW.VID              " "
 ERICSSON.VID             " "
 HERC102.VID              " "
 HERC112.VID              " "
 QPERR.HLP              QuickPascal additional help files.
 QPGRAPH.HLP              " "
 NOTES.HLP                " "

 Additional reference words: distribution directory disks qp


 27. How to View Registers When Debugging Assembly Modules

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | docerr
 Last Modified:  6-SEP-1989    ArticleIdent: Q46768

 In the data sheet for QuickPascal, there is the following statement
 that describes the ability of QuickPascal to display CPU registers:

    In addition, the integrated debugger supports debugging assembly-
    language routines imported into your program with the $L directive,
    including viewing of CPU registers.

 This point requires elaboration to successfully view the registers.

 As an example, if you have an assembly module named foo.asm that will
 be invoked from your Pascal code, then you can view registers when you
 have a {$L foo.obj} in your code and you have the assembler source
 file present in the current directory.

 When you start debugging and you enter into a procedure from foo.obj,
 you will automatically see the registers in the debug window, and in
 another window you will see the assembler file.


 28. Incorrect Syntax in Var-String Checking Sample Procedure

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | docerr
 Last Modified: 18-AUG-1989    ArticleIdent: Q46804

 The section on Page 78 of Microsoft's "Pascal by Example" that
 describes var-string checking has a sample procedure header of
 incorrect syntax.

 The procedure is declared as follows:

    PROCEDURE print_str ( data_str : STRING[20]);

 Compiling this statement results in the following error message:

    ERROR 19: ")" expected

 The procedure should be declared as follows:

    PROCEDURE print_str ( data_str : STRING);


 29. QuickPascal Uses LIM 4.0 for EMS Swapping When Enabled

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 25-AUG-1989    ArticleIdent: Q46842

 Problem:

 When attempting to invoke QuickPascal Version 1.00 with the /SWAP:EMS
 command line option, the following error message occurs:

    Cannot open swap file

 This error occurs with 2 MB of expanded memory.

 Response:

 QuickPascal Version 1.00 supports LIM specification 4.0 EMS. (the 3.2
 LIM specification is not supported.)

 To use this option, you must have at least 1 MB of free expanded
 memory and a device driver that supports LIM specification 4.0.

 For more information please see Page 4 of the README.DOC file
 contained within the QuickPascal on-line help system.


 30. QP with /Zi Does Not Place CodeView Information into .EXE

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified:  6-SEP-1989    ArticleIdent: Q47015

 In QuickPascal Version 1.00, it is not possible to use /Zi to get
 CodeView information into the executable file.

 CodeView will run QuickPascal executables, but it comes up in assembly
 mode because there is no symbolic information.

 Currently, there is no way to get CodeView information into the
 executable file.

 This feature is under review and will be considered for inclusion in a
 future release.


 31. QuickPascal Sound Function Sounds Different Than Turbo

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist1.00
 Last Modified:  6-SEP-1989    ArticleIdent: Q47017

 I have a program that uses the sound function in the CRT unit. It
 sounds different when I run it in QuickPascal than when I run it in
 Turbo.

 The program plays a short sound that increases in frequency. When I
 run it in Turbo, it sounds crisp; however, when I run it in
 QuickPascal, it sounds very grainy and rough.

 The following repeat loop generates a different quality of sound when
 run under the two products:

     i := 440;
     repeat
         sound(i);
         delay(12);
         inc(i,5);
     until i > 880;
     nosound;

 This loop calls the standard sound function from the QuickPascal unit
 CRT. It generates slightly different sound than TurboPascal.

 If it is mandatory that this loop sound identical to Turbo (for
 compatibility issues), you could replace the built-in sound and
 nosound functions with the following two procedures in your source
 code:

 procedure mysound( hz : word );
 var ps    : byte;
     count : word;
 begin
     if hz > 0 then
         begin
             ps := Port[97];
             if (ps and $03) = 0 then
             begin
                 Port[97] := ps or $03;
                 Port[67] := 182;
             end;
             count := 1193280 div hz;
             Port[66] := Lo(count);
             Port[66] := Hi(count);
         end;
 end;

 procedure mynosound;
 begin
     Port[97] := Port[97] and not $03;
 end;

 Then, call your own sound functions (mysound and mynosound) instead of
 the regular sound function in CRT. For example, the above repeat loop
 would now look similar to the following:

     i := 440;
     repeat
         mysound(i);
         delay(12);
         inc(i,5);
     until i > 880;
     mynosound;

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


 32. {$E} and {$O} Directives

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified:  6-SEP-1989    ArticleIdent: Q47022

 Two compiler directives, {$E} and {$O}, are accepted by the
 QuickPascal (QP) compiler, yet no help or documentation is available
 on these directives outside of the README.DOC.

 The directives are accepted by the compiler for compatibility with
 TurboPascal. These two directives are actually ignored.

 The {$E} directive controls the usage of the emulator math package
 with the Borland product, while the {$O} directive controls overlay
 code generation. Neither of these directives is supported under QP.

 Information concerning QP and these two directives is in the
 README.DOC file included with the QuickPascal package.


 33. "Error 131: Invalid Real Operation" Constant Out of Range

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist1.00 docerr
 Last Modified:  6-SEP-1989    ArticleIdent: Q47032

 The program shown below generates the following error message:

    Error 131: Invalid real operation

    An operation on two real types in this statement resulted in an
    invalid floating-point operation. Either an overflow occurred or
    an attempt was made to divide by zero.

 This explanation may be misleading because the error also occurs
 when a declared constant is out of range.

 The following program illustrates this problem:

 PROGRAM test
 CONST
   co : COMP = 9e20;       { this value is out of range   }
 BEGIN                     { The range should be          }
 END.                      {    9.2E-18 to 9.2E+18        }

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


 34. QuickPascal Does Not Support Multiple Debug Sessions

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified:  6-SEP-1989    ArticleIdent: Q47033

 Question:

 If I load two different programs into QuickPascal, set a breakpoint in
 the first program, and try to execute the second program, I get the
 following error and QuickPascal switches back to my first program:

    Cannot set breakpoint

 On-line help for this error indicates that a breakpoint was set on a
 line that does not contain executable code.

 The breakpoint within my first program is set correctly and I did not
 try to set a breakpoint within my second program. What causes this
 problem?

 Response:

 Microsoft QuickPascal Version 1.00 does not support multiple debug
 sessions. You must clear the breakpoints from your first program
 before you try to run or trace your second program. When you run a
 second program, all debug information for the first program is lost.


 35. QuickPascal Menu Colors Not Restored on VGA Adapters

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified:  6-SEP-1989    ArticleIdent: Q47034

 When using a VGA display adapter, running or debugging a graphics
 program while inside the QuickPascal (QP) environment causes the menu
 colors to be remapped if the video mode is changed and not restored
 before the control returns to the QuickPascal environment. This
 happens in either of the following situations:

 1. You trace into a program that changes the graphics mode. After the
    colors change, restart or break the program.

 2. You set the video mode and do not restore the default mode before
    the program ends.

 This is expected behavior on an VGA display. To prevent this from
 occurring, you must invoke QuickPascal with the /S switch.

 The /S option is used to save the color palettes on the VGA. By
 default, this switch is not active. /S must be used if you have a VGA
 and your graphics program is manipulating the VGA color palettes. This
 switch causes the color palettes to be saved to disk or memory.
 QuickPascal swaps the palettes back when returning to the QP
 environment from your program.

 If the menu colors are not correct after you complete these
 procedures, the colors may have been stored in the QP.INI file. In
 this case, erase the QP.INI file so that defaults will be used the
 next time you start QuickPascal.


 36. QuickPascal Evaluates All Compiler Directives for Syntax

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified:  6-SEP-1989    ArticleIdent: Q47116

 QuickPascal evaluates all directives, even if the directive is
 contained in a block that is not defined.

 On Page 250 of "Pascal by Example," the following text is presented:

    Conditional directives produce different code from the same source
    file if a conditional identifier is defined. The conditional
    directives are, in effect, a variation of the IF control statement.
    If a condition is true, code between the {$IFxxxCondition} and
    {$ENDIF} directives is compiled. If the condition is false, the
    compiler skips the code between the two directives. An optional
    {$ELSE} directive provides further control.

 The part about "If the condition is false..." is misleading. The
 compiler skips until it finds a "{$". The compiler is looking for
 {$ENDIF}. If you have any directives in that block, the compiler will
 check to make sure they are valid.

 The following code illustrates the problem:

 {$IFDEF VER40}
     {$k-}
 {$ENDIF}

 program foo;
 begin
     writeln('This is a test.');
 end.

 Even though VER40 is not defined, the compiler will complain that
 {$k-} is not a valid directive.


 37. _HRES16COLOR Video Mode Constant Spelled Incorrectly in Help

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | docerr
 Last Modified:  6-SEP-1989    ArticleIdent: Q47251

 In Microsoft QuickPascal Version 1.00's on-line help, the videomode
 constant "_HRES16COLOR" is spelled incorrectly as "_HRES16COL". It is
 incorrect only in the Index under Video modes.

 The error is under review and will be corrected in a future release of
 QuickPascal.

 To see this incorrect information, invoke QuickPascal, bring up the
 Help.Index menu, choose V on the selection bar, and then choose Video
 modes.


 38. Quick Environments Do Not Notice If Floppy Drive Isn't Ready

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | S_QuickC S_QuickASM
 Last Modified:  6-SEP-1989    ArticleIdent: Q47252

 If you enter one of the QuickC, QuickAssembler, or QuickPascal
 environments, do a File.Open, type in "A:\" to pull up the list of
 files available on Drive A, and the floppy drive is not ready, the
 environment simply waits. If you type "A:\*.*", the QuickPascal
 environment will still wait. The QuickC and QuickAssembler packages
 are better in that they produce an error message that says that an
 invalid file specification was entered. However, the Help menu does
 not mention that this problem can be caused by the drive not being
 ready.

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


 39. Help for "Cannot Open Swap File" Is Incorrect in QuickPascal

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | docerr
 Last Modified:  6-SEP-1989    ArticleIdent: Q47394

 When bringing up the Microsoft QuickPascal Version 1.00 environment,
 the help for the following error message incorrectly states that this
 error occurs when swap is OFF:

    Cannot open swap file

 The help for the error message should state that this error occurs
 when swap is turned ON and there is insufficient disk space or EMS
 memory for the swap file. In addition, this error message can also
 occur when the directory specified for the swap file does not exist.

 The following command line reproduces the error if the directory
 "C:\SWAP" does NOT exist:

    qp /swap:on=c:\swap\swap.dat


 40. Addr() Address Function and @ Operator Example

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 15-SEP-1989    ArticleIdent: Q47479

 The following is a description of the QuickPascal function Addr(), and
 the at-sign operator "@".

    Syntax:     FUNCTION Addr ( VAR id : <ident> ) : Pointer;

 The Addr() function returns the memory address of id, where id may be
 a variable, procedure, or function identifier. The return value of
 Addr() is a 32-bit pointer containing two 16-bit values representing
 the segment and offset of the location of id in memory.

 The at-sign "@" operator is equivalent to the Addr() function.

 The following are examples showing the use of the Addr function and
 the at-sign "@" operator:

 Example 1: Using the Addr() Function
 ------------------------------------

 PROGRAM xAddr;
 VAR
     p : pointer;
 BEGIN
     p := Addr (p);
     Writeln ('The address of p is at ', Seg(p^), ':', Ofs(p^));
 END.

 Example 2: Using the @ Operator
 -------------------------------

 PROGRAM At_Operator;
 VAR
     p : pointer;
 BEGIN
     p := @p;
     Writeln ('The address of p is at ', Seg(p^), ':', Ofs(p^));
 END.


 41. Select Text Fails on Toshiba T1000 with DOS 2.11 in ROM

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist1.00
 Last Modified:  6-SEP-1989    ArticleIdent: Q47483

 The Toshiba T1000 with DOS 2.11 in ROM does not select text with the
 SHIFT+arrow keys in the Microsoft QuickPascal environment.

 Microsoft has confirmed this to be a problem with QuickPascal Version
 1.00. We are researching the problem and will post new information as
 it becomes available.


 42. Get_area := Self.height; Incorrect in "Pascal by Example"

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | docerr
 Last Modified: 11-SEP-1989    ArticleIdent: Q47485

 In Section 15.5, on Page 234 of Microsoft QuickPascal's "Pascal by
 Example," there is a typographical error in the example program
 OBJECTDE.PAS. The second line up from the bottom of the page is
 printed as follows:

    get_area := Self.height;

 The line should be as follows:

    get_area := Self.area;

 This program is also included in the on-line programming examples that
 can be called up from the QuickPascal environment. The on-line example
 contains the correct code.


 43. Illegal File Specification

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | S_QuickC
 Last Modified: 15-SEP-1989    ArticleIdent: Q47611

 No checking is done on path specifications that are entered in the
 Options.Environment menu. Thus, if an invalid path is given for the
 EXE directory, QuickPascal generates the following error:

    Illegal file specification:
    <path and file name here>

 Neither QuickC nor QuickPascal checks to be sure that a path
 specification entered in the Options.Environment menu is valid. Thus,
 if you were to enter the path incorrectly, you would not find out
 until an attempt is made to use the path.

 This is not considered a problem in either QuickC or QuickPascal.


 44. Method Compiler Directive {$M+} Is Disabled by Default

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | docerr
 Last Modified:  6-SEP-1989    ArticleIdent: Q47626

 In Section 15.3.1, Page 227 of Microsoft QuickPascal's "Pascal by
 Example," it states that "(The {$M+} directive is enabled by
 default.)" This is incorrect. The default for the Method compiler
 directive is disabled, i.e., {$M-}. You must explicitly enable Method
 checking with {$M+} if you want to use objects and object-oriented
 extensions. In Appendix B, Page 247, the proper default is listed.


 45. File.Open Requires an Extension After Specifying *.XXX

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | S_QuickC buglist1.00
 Last Modified:  6-SEP-1989    ArticleIdent: Q47633

 When you invoke the File.Open menu and specify, for example, *.YYY, QP
 shows the .YYY files in the File List box. If you type in the filename
 such as XXX without the .YYY extension, you receive the following from
 QP:

    'XXX.YYY' does not exist
           Create?

 QP doesn't know that you are referring to XXX.YYY, so it assumes the
 file does not exist. You must include the extension. This also applies
 to QuickC.

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


 46. Quick Pascal 1.00 Does Not Allow Truncation of Large Files

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified:  6-SEP-1989    ArticleIdent: Q47696

 When attempting to load a file that is too large to fit into the
 environment, Quick Pascal 1.00 does not give the option of truncating
 the file in order to load it.

 This option is under review and will be considered for inclusion in a
 future release of Quick Pascal.


 47. Error 50 and Error 127 in Program FirstGraphics

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | docerr
 Last Modified:  6-SEP-1989    ArticleIdent: Q47742

 On Pages 173 and 174 of the Microsoft QuickPascal "Pascal by Example"
 manual, the example program FirstGraphics contains two errors.

 The following

    _MoveTo( vc.NumXPixels DIV 4, vc.NumYPixels * DIV 4);

 will produce

    Error 50: Error in expression

 at compile time. To correct this problem, insert a 3 between * and
 DIV.

 Also,

    _SetVideoMode(_DefaultMode);

 will produce

    Error 127: Invalid variable reference

 at compile time. Assign the function call to an integer such as a or i
 that has already been declared as an integer in the program, as
 follows:

    a := _SetVideoMode(_DefaultMode);

 Pascal functions, unlike C functions, require the returned value to be
 assigned to a variable.


 48. Mixed Pascal/Assembly Example (switch.asm) Does Not Work

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | docerr hang assembly runtime
 Last Modified:  6-SEP-1989    ArticleIdent: Q47771

 The example program in "Pascal By Example," on Page 165, does not work
 as documented. Occasionally the computer locks up, nothing happens
 when the example is executed, or the following error is generated:

    Run-time Error 200: Division by Zero

 To correct the program, add the instructions {$F+} and {$F-} around
 the external declaration for switch().

 This error occurs because the program example neglects the fact that
 an assembly language procedure must be called with a far call. The
 {$F+} turns far calls on, {$F-} turns far calls off. Thus, the example
 program should read as follows:

 {$F+}
 {$L switch}
 PROCEDURE switch(VAR a, b: Word); EXTERNAL;
 {$F-}

 .
 .
 .

 switch(x, y)

 Also, the assembly language file given should have the following lines
 appended to its end:

 CODE ENDS
      END


 49. Index Incorrectly States That a "Single" Is 6-Bytes Long

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | docerr
 Last Modified: 11-SEP-1989    ArticleIdent: Q47799

 The Index entries for the "Single" and "Real" types read as follows:

    Single       Stores 6-byte floating point number
    Real         Stores 6-byte floating point number

 The entry for Real is correct. However, the entry for Single should
 read as follows:

    Single       Stores 4-byte floating point number.

 This information is stated correctly in "Pascal By Example" on Page
 15.

 It is also documented correctly in the Online Help, following a
 different query path as shown below:

 1. Pull down the help menu.

 2. Choose "Contents."

 3. Choose "Data Types."

 4. Choose "Single."

    This screen correctly states that a Single occupies 4 bytes.


 50. Changing Directory/Drive in Shell Changes Them in Picker

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist1.00
 Last Modified: 11-SEP-1989    ArticleIdent: Q47819

 Question:

 I found that changing drives in a shell changes them in the picker. Is
 this correct behavior?

 To reproduce the problem, do the following:

 1. Start QuickPascal (QP) (a file must not have been opened during the
    session).

 2. Call File.Open and note your current drive and directory, then
    cancel.

 3. Execute File.DOS Shell.

 4. Change the drive or directory and exit the shell.

 5. Call File.Open.

 The current drive/directory now matches the drive/directory made
 current while in the shell. Changes made in the shell should not
 affect the current drive/directory of the environment. You should be
 able to change these only with the file picker dialog.

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



 51. QP Unit Swapped In for Trace Isn't Swapped Back Out

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist1.00
 Last Modified:  6-SEP-1989    ArticleIdent: Q47999

 If nine windows are opened in QuickPascal (QP) Version 1.00, and a
 trace into a program that uses a unit that isn't loaded in a window is
 made, one of the open files is swapped out so that QP can trace into
 the unit.

 The unit remains in the swapped window upon program completion. If the
 traced program is in the only unsaved window, it is the one swapped
 out. At program completion, the traced program is unavailable for
 further editing (even though it is saved to disk).

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


 52. Help for Run-Time Error 103 Is Inaccurate

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist1.00 docerr
 Last Modified:  6-SEP-1989    ArticleIdent: Q48002

 The help for run-time 103 states "An I/O operation was attempted on an
 unopened file." Attempting an I/O operation on an unopened file
 actually generates either run-time 104 or 105. Run-time 103 occurs if
 you try to close a file that was not opened.

 The following are the run-time errors returned when
 procedures/functions are used with unopened (or unassigned) files:

    Func/Proc   Error Returned
    ---------   --------------

    Erase             3
    Rename            3
    Reset           102
    Rewrite         102
    BlockRead       103
    BlockWrite      103
    Close           103
    FilePos         103
    FileSize        103
    Flush           103
    Seek            103
    Eof             104
    Eoln            104
    SeekEof         104
    SeekEoln        104
    Read            104
    Readln          104
    Write           105
    Writeln         105


 53. Getting Help on QuickPascal Errors

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | documentation
 Last Modified: 21-APR-1990    ArticleIdent: Q48055

 To obtain help on QuickPascal error numbers when they are not produced
 by the environment, there are several special steps that must be
 taken. Note that these steps are not required by QuickC due to its
 support of the HELPFILES environment variable.

 Contexts and help text for all of the errors produced by QuickPascal
 are contained in the QPERR.HLP help file. This file is used only when
 help is requested from an error dialog box. For this help file to be
 accessed by the rest of the QuickPascal environment, the following
 copy should be made at the DOS prompt:

    COPY QP.HLP /b + QPERR.HLP /b

 Note: QPERR.HLP should not be erased because it is still the file that
 error dialog boxes use to locate help.

 The contexts of these error messages are in the form E.P####, where
 #### is the error number you are looking for, left-padded with zeros
 to four places. For example, the context for error number 32 would be
 E.P0032.

 Run-time error messages can be searched for by using the format
 E.R####.  For example E.R0202.  (note the R for run-time)

 To search for error number 32, type E.P0032 in an editor window,
 highlight the entire phrase, and then press F1 to search for the
 context.


 54. Address of Function in Debug Window Not Supported

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist1.00
 Last Modified: 15-SEP-1989    ArticleIdent: Q48225

 In the debug window, QuickPascal does not show the value of a function
 or procedure correctly. Instead of showing the actual address, it
 shows the value as 0000:0000.

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

 Viewing the address of a function in the debug window currently is not
 supported. This feature will be considered for inclusion in a future
 release.

 To demonstrate the problem, trace into a program that has a function
 or procedure in it. Bring up the debug window and type the following:

    @foo

 Foo is the name of the function or procedure in question. The @
 operator should cause the address of foo to be displayed, but instead,
 the value 0000:0000 is displayed.


 55. Watch Window Should Be Tiled to Avoid Overlapping

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist1.00
 Last Modified:  6-SEP-1989    ArticleIdent: Q48237

 Adding a watch to QuickPascal (QP) Version 1.00 creates a completely
 overlapping debug window, which is impractical for the purpose of
 watching variables. Continued debugging overlaps ALL of the watch
 window, again defeating the purpose. It is necessary to resize each
 time. The best way to handle this is by tiling your existing windows.

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


 56. File.Save to a Nonexistent Drive Gives Incorrect Error

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist1.00
 Last Modified: 27-SEP-1989    ArticleIdent: Q48239

 If you do a File.Save on a machine with one floppy drive by entering
 B:\XXX.PAS as the filename, QuickPascal (QP) gives the following error:

    Illegal file specification:
         'B:\XXX.PAS'

 B:\XXX.PAS is a valid filename. The error SHOULD say that the drive
 does not exist.

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


 57. Environment Control of Search Path for Source File

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 11-SEP-1989    ArticleIdent: Q48277

 Question:

 Will adding a search path to the source section of environment control
 affect opening a source file once QuickPascal (QP) has started?

 Response:

 No; the source path section of the environment control has no effect
 on opening any files once QuickPascal has started. If you want to open
 a file in a directory other than the current working directory, you
 must select that directory from the "Dirs / Drives:" window under the
 open menu.

 However, if you were to add a path to the source section of the
 environment menu, and SAVE it, you could quit QuickPascal and then
 enter a file on the command line after QP and it will find the file
 and load QuickPascal with that file. To view this, try the following:

 1. Make a directory named "c:\test", and place a sample .PAS file
    there.

 2. Start QuickPascal and go to the environment menu under "options".

 3. Enter "c:\test" on the source line, select SAVE, and quit
    QuickPascal.

 4. On the command line, you can enter "qp file.pas" from any directory
    and QuickPascal will find your file.


 58. QP 1.00: Marking Text Blocks: Cannot Use Mouse to Mark End

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 11-SEP-1989    ArticleIdent: Q48278

 In the QuickPascal (QP) Version 1.00 environment, use the following
 procedure to mark a text block with the keyboard:

 1. Move the cursor to the desired beginning location (using the
    keyboard or mouse).

 2. Press ^K B, to mark the beginning of the text block.

 3. With the arrow keys, move the cursor to the desired end location.

 4. Press ^K K to mark the end of the text block.

 If the mouse is used to move the cursor to the end of the text block,
 ^K K will fail, and the text block will not be highlighted.


 59. Description of Compiler Option: Var-String Checking

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | $v+ $v- {$v+} {$v-}
 Last Modified: 21-SEP-1989    ArticleIdent: Q48443

 The Var-String checking option controls whether or not strict type
 checking is performed on variable-length string parameters (in
 functions and procedures). When this directive is enabled, formal and
 actual parameters must be of IDENTICAL string types. When this
 directive is disabled, formal and actual string parameters can have
 different declared lengths (e.g. you can pass string[6] type data to
 functions that expect string[8] type data).

 The following program compiles only if Var-String checking is turned
 off. If Var-String checking is enabled, the compiler produces a type
 mismatch error.

 PROGRAM    vartest;
 PROCEDURE  print_str( var data_str : string);
    BEGIN
      writeln(data_str:10);
    END;

 VAR
    data_str1 : STRING[20];
    BEGIN
      data_str1:= 'abcdefghijklmnopqrst';
      print_str(data_str1);
      data_str1:= 'abc';
      print_str(data_str1);
    END.


 60. How to Manually Set Up QuickPascal on a Hard Disk

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 26-SEP-1989    ArticleIdent: Q48738

 The following information explains how to manually set up Microsoft
 QuickPascal Version 1.00 for a hard disk. It shows you how to set
 up in the same way as the SETUP.EXE program.

 This information demonstrates how to set up QuickPascal under the
 directory "QP" on Drive C. Please note that this is not the only
 configuration possible.

 1. Create the following directories:

       C:\QP
       C:\QP\SAMPLES
       C:\HLP

 2. Add the following to your AUTOEXEC.BAT file:

       SET PATH=C:\QP;C:\QC\HLP

    You may place this in a separate batch file if you prefer.
    Note: It is very important that you do not add spaces in or
    after the PATH variable. For example, "SET PATH= C:\QP;C:\QP\HLP"
    and "SET PATH=C:\QP;C:\QP\HLP " do not work correctly.

 3. Add the following to your CONFIG.SYS file:

       FILES=20
       BUFFERS=20

    You must reboot your machine for this to take effect.

 4. Copy the following files to C:\QP:

       File            5.25-Inch Disk          3.50-Inch Disk
       ----            --------------          --------------

       MOUSE.COM       Setup/Utilities         Setup/Program/Utilities
       MSHERC.COM      Setup/Utilities         Setup/Program/Utilities
       QPMKKEY.EXE     Setup/Utilities         Setup/Program/Utilities
       BRIEF.KEY       Setup/Utilities         Setup/Program/Utilities
       EMACS.KEY       Setup/Utilities         Setup/Program/Utilities
       ME.KEY          Setup/Utilities         Setup/Program/Utilities
       QP.KEY          Setup/Utilities         Setup/Program/Utilities
       EPSILON.KEY     Setup/Utilities         Setup/Program/Utilities
       QP.EXE          Program                 Setup/Program/Utilities
       QPL.COM         Program                 Setup/Program/Utilities
       QPL.ERR         Program                 Setup/Program/Utilities
       SYSTEM.QPU      Libraries               Libraries
       CRT.QPU         Libraries               Libraries
       DOS.QPU         Libraries               Libraries
       GRAPH.QPU       Libraries               Libraries
       MSGRUTIL.QPU    Libraries               Libraries
       MSGRAPH.QPU     Libraries               Libraries
       PRINTER.QPU     Libraries               Libraries
       COURB.FON       Libraries               Libraries
       HELVB.FON       Libraries               Libraries
       MODERN.FON      Libraries               Libraries
       ROMAN.FON       Libraries               Libraries
       SCRIPT.FON      Libraries               Libraries
       TMSRB.FON       Libraries               Libraries
       LEARN.EXE       MS Express              MS Express/Advisor
       LEARN.PIF       MS Express              MS Express/Advisor
       QPCBT.CTX       MS Express              MS Express/Advisor
       QPCBT.SCN       MS Express              MS Express/Advisor
       QPCBT.SOB       MS Express              MS Express/Advisor
       ATT6300.VID     MS Express              MS Express/Advisor
       CGASNOW.VID     MS Express              MS Express/Advisor
       HERC102.VID     MS Express              MS Express/Advisor
       ERCSSON.VID     MS Express              MS Express/Advisor
       HERC112.VID     MS Express              MS Express/Advisor

 5. Copy the following to C:\QP\HLP:

       File            5.25-Inch Disk          3.50-Inch Disk
       ----            --------------          --------------

       README.DOC      Setup                   Setup/Program/Utilities
       PACKING.LST     Setup                   Setup/Program/Utilities
       QP.HLP          MS Advisor              MS Express/Advisor
       QPENV.HLP       MS Advisor              MS Express/Advisor
       QPERR.HLP       MS Express              MS Express/Advisor
       QPGRAPH.HLP     MS Express              MS Express/Advisor
       NOTES.HLP       MS Express              MS Express/Advisor

 6. Copy all *.PAS files to C:\QP\SAMPLES.

 Microsoft QuickPascal Version 1.00 should now be set up on your hard
 disk.


 61. Error 19 Caused By Missing Space in Expression

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist1.00
 Last Modified: 26-SEP-1989    ArticleIdent: Q48843

 Under QuickPascal Version 1.00, 'error 19: ")" expected', occurs on
 any expression where a real number with no digits after the decimal
 point exists with a closing parenthesis directly to the right.
 Inserting a space or a 0 (zero) after the decimal eliminates the
 error.

 The following valid expression

    x := (1. + 1./9.);

 generates the following error and marks the decimal before the closing
 parentheses:

    error 19: ")" expected

 No error is generated if a space is inserted between the decimal and
 the closing parentheses, as follows

    x := (1. + 1./9. );

 or a zero is inserted after the decimal, as in the following:

    x := (1. + 1./9.0);

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


 62. Problem in Options Environment Causes Vague Error

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist1.00
 Last Modified: 26-SEP-1989    ArticleIdent: Q48946

 If an incorrect path is entered in the Options.Environment window in
 the space for the EXE directory, an error message pop-up is returned
 when a compile is attempted. An incorrect path is a path to a
 non-existent directory or a directory path that exceeds the
 64-character length permitted by MS-DOS. The following is the message
 that is returned:

    +------------------------+
    |   Source:  xxxxx.PAS   |
    |   Cannot create file   |
    |    < OK >    <Help>    |
    +------------------------+

 This error message doesn't clarify the cause of the error. QuickPascal
 should return an error message that states "Invalid Executable Path"
 (or equivalent). However, since MS-DOS doesn't return enough precise
 error information, a clearer message is currently impossible.

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

 To correct the problem, make sure that the environment path is valid,
 i.e., set to an existing directory, and/or is fewer than 64 characters
 in length.


 63. QP Reports Incorrect Number of Lines Compiled If Lines > 65535

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist1.00
 Last Modified: 26-SEP-1989    ArticleIdent: Q48986

 While compiling, QuickPascal displays a running total of the number of
 lines compiled in the currently compiling module, as well as the total
 number of lines in all modules compiled so far. This progress
 information is correct for programs up to 65,535 total lines. For
 larger programs, after compiling the 65,535th line, the counter wraps
 around and begins at 0 (zero) again.

 Therefore, when compilation is complete, QuickPascal displays the
 actual number of lines minus 65,536. So, if your program has 65,540
 lines, QPL displays 4 lines compiled instead of the correct number of
 lines. This problem occurs both in the environment and with the command
 line compiler QPL.

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


 64. Modification of Type Comp with Negative Exponent

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist1.00
 Last Modified:  2-OCT-1989    ArticleIdent: Q48990

 When a variable of type comp is modified using the Debug.Modify value
 option in QuickPascal, unexpected results may occur. When the variable
 is modified using scientific notation to have a negative exponent,
 e.g. 1.5E-6, the resulting value that is stored in that variable is
 incorrect, e.g. 2.4309066601E+14.

 To reproduce the error, use the following code fragment and carry out
 the steps outlined below (any code that has a variable of type comp
 can be substituted):

 Code Fragment
 -------------

    program compmod (input, output)

    var comptest: comp;

    begin
    end.

 Use the following steps to reproduce the problem:

 1. Begin tracing through the program using the F8 key.

 2. Enter the Debug window and add a watch on the variable comptest.

 3. Enter the Debug window and select "modify value". Modify the comptest
    variable to be a value with a negative exponent (e.g. 6.6E-6). The
    value in the watch value demonstrates the error.

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


 65. Make Menu Doesn't Show Product as .QPU When Source Is a Unit

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist1.00
 Last Modified:  2-OCT-1989    ArticleIdent: Q49009

 When compiling a stand-alone unit, the make menu should change to show
 that the product is <file>.QPU instead of <file>.EXE. This is not the
 case in QuickPascal Version 1.00. This could be confusing since a
 compilation finishes without error and the menu shows that <file>.EXE
 was produced when in actuality <file>.QPU was produced.

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


 66. On-Line Help Incorrectly Describes Range Checking

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | docerr
 Last Modified:  2-OCT-1989    ArticleIdent: Q49116

 Use the on-line help to look up compiler options. The $R (range
 checking) directive is incorrectly listed in the on-line help as being
 turned on ($R+) for default. The actual default is off ($R-).


 67. Characters Beyond Column 255 Become Reversed in Editor

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist1.00 QP
 Last Modified:  2-OCT-1989    ArticleIdent: Q49117

 When a long line is typed in the QuickPascal editor and the 255th
 character is reached, following characters are displayed in reverse
 order and a beep is sounded for each character. Characters beyond
 Column 270 scroll off the screen. The following is an example:

                              255            270
                               |              |
    hello there hello there helolleh ereht olle

 Although QuickPascal won't let you view more than 255 character lines,
 it maintains data after the 255th column. These characters, however,
 are useless because they are preserved in reverse order. In addition,
 lines longer than 128 in length are longer than the maximum allowable
 by the compiler.

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


 68. Real Variables Can Be Modified to Less Than Minimum Value

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist1.00
 Last Modified:  2-OCT-1989    ArticleIdent: Q49118

 When using QuickPascal's debugging features to modify real values, it
 is possible to specify an incorrect value. The results vary for
 different types of reals.

 When most real variables are modified to below their allowable
 minimum, they are modified by the environment to become 0 (zero).
 However, for the types double and extended, the value severely loses
 accuracy between X.Xe-308 and X.Xe-325. These ranges vary slightly
 depending on the values of X.

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


 69. File.DOS Shell While Running Program Stops Execution

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist1.00
 Last Modified: 10-OCT-1989    ArticleIdent: Q49317

 In QuickPascal Version 1.00, if you are using F8 to step through your
 program and choose DOS shell from the File menu, when you exit from
 that shell, the program you were running is restarted.

 To demonstrate this behavior, use the following procedure:

 1. Load the following sample program into the QuickPascal environment:

       program hello (output);

       begin
               writeln ('hello');
               writeln ('goodbye');
       end.

 2. Compile the program by invoking Build Main File from the MAKE menu.

 3. Press F8 to step to the begin line.

 4. Press F8 again to step to the writeln ('hello'); line.

 5. Invoke DOS Shell from the File menu. QuickPascal will shell to the DOS
    command prompt.

 6. Type "exit" (without the quotation marks) at the DOS command prompt
    to quit that shell and return to the QuickPascal environment.

 Now, if you press F8 again, you might expect to execute the
 writeln('goodbye'); line because that is exactly where you left off.
 However, QuickPascal starts executing from the beginning again.

 Microsoft has confirmed this to be a problem with QuickPascal Version
 1.00. This feature is under review and will be considered for changes
 in a future release.


 70. Watching Out-of-Range Integers

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist1.00
 Last Modified: 10-OCT-1989    ArticleIdent: Q49320

 Problem:

 In the program below, the value of -32768 is assigned to an integer
 called X. I want to watch -X and see 32768 in the watch window. However,
 QuickPascal shows -32768 when I watch -X.

 Program test;

 var X : integer;

 begin
     X := -32768;
 end.

 Response:

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

 QuickPascal handles this condition correctly up to the limit of an
 integer. For example, if you assign X the value of -32767 and then
 watch -X, QuickPascal displays 32767 in the watch window.

 This does not work for -32768 because you have exceeded the range of
 an integer. If you plan to store an integer larger than plus or minus
 32767, you must use the appropriate data type, longint.

 In the program below, X is now a longint. You can now watch -X and see
 32768 in the watch window.

 Program Example
 ---------------

 Program test;

 var X : longint;

 begin
     X := -32768;
 end.


 71. QuickPascal 1.00: A Program Can Use Up to 81 Units

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 10-OCT-1989    ArticleIdent: Q49499

 As documented in "Pascal by Example" on Page 88, a QuickPascal Version
 1.00 program can use up to 81 units.

 A "unit" is defined as "a related collection of declarations and
 procedures."

 For more information on units, refer to Pages 87-93, Chapter 7, the
 section titled "Units", in the Microsoft QuickPascal "Pascal by
 Example" text.


 72. How to Process Command-Line Arguments in QuickPascal

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 14-FEB-1990    ArticleIdent: Q58319

 Question:

 How do I process command-line arguments in QuickPascal?

 Response:

 Command-line arguments are accessed through two functions included in
 the SYSTEM unit: ParamCount and ParamStr. ParamCount returns the
 number of command-line arguments, while ParamStr can return a specific
 command-line argument in the form of a string. See the sample program
 below or see sample programs in the online help that show how to
 process command-line arguments.

 These online help sample programs are as follows:

     PARAMS.PAS
     SUMINT.PAS
     SUMREAL.PAS
     EXITHALT.PAS

 These files can be found under "Example Programs" on the Contents menu
 in the online help (that is, Help.Contents.Example
 Programs.-program-name-, where -program-name- is the name of the
 sample program).

 Code Sample
 -----------

 The following program also shows how to process command-line
 parameters:

 PROGRAM foo;

 VAR
     count,
     i       :  Word ;

 BEGIN
         { Display each command-line argument. }

         Writeln( 'Command-line arguments:' );
         Writeln;

         count := ParamCount;            { Number of parameters }

         FOR i :=0 TO count DO
                 Writeln( 'Parameter ', i, '   ', ParamStr( i ) );

 END.

 Compile the above program and then run it by typing the name of the
 .EXE file followed by various argument strings separated by spaces.


 73. Clicking on Help Contents Dots Might Not Work in QuickPascal

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 30-NOV-1989    ArticleIdent: Q49713

 When using the right mouse button to select help contents, clicking on
 the dots associated with a desired help topic might have no result.

 To accurately choose an item from the help contents window, click on
 the desired word or phrase next to the dot.


 74. Run-Time Error 105 Caused by Huge Array

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 30-NOV-1989    ArticleIdent: Q49738

 QuickPascal's run-time error 105, which normally means that the file
 specified was not open for output, is also caused by having an array
 indexed from 0 to 65535. The following code demonstrates this:

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

 PROGRAM test;
 VAR
     i : LongInt;
     memflag : ARRAY[0..65535] of Integer;
 BEGIN
     FOR i := 0 to 65535 DO
     BEGIN
       writeln(i);
       memflag[i] := 0;
     END;
 END.

 The above code terminates with error 105. If the array is
 declared to be of type Byte, the program terminates later in the code.
 If the array is indexed any other way (e.g. [1..65535] or [0..65534]),
 the problem does not occur and either error 49 ("Structure too big") or
 error 146 ("Too many variables in the data segment") is displayed.


 75. Break When Expression Is True in Debug Breaks Incorrectly

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist1.00
 Last Modified: 30-NOV-1989    ArticleIdent: Q50131

 If you set a breakpoint (Break When Expression Is True) in one file
 and then run another program that has the same variable, the second
 program breaks when the expression is true from the first program.

 The following demonstrates this problem.

 1. Start with the following programs in two separate tiled windows:

      PROGRAM   foo1;               PROGRAM   foo2;

      VAR  i : INTEGER;             VAR  i : INTEGER;

      BEGIN                         BEGIN

         FOR i := 1 TO 4 DO            FOR i := 2 TO 10 DO
            WRITELN ('i = ',i);           WRITELN ('i = ',i);

      END.                          END.

 2. From foo1 window, go to (Debug.Set Breakpoint.Break When Expression
    Is true) and add "i = 3" (without the quotation marks) in the
    Expression: box.

 3. Press the F5 key to run the foo1. The program will run and print "i
    = 1" and "i = 2" in the output window, then break.

 4. Switch to foo2 window and press the "F5" key to run foo2. The
    program will run and print "i = 2", then break. This should not
    happen. Instead, it should print "i = 2" through "i = 10".

 Microsoft has confirmed this to be a problem with QuickPascal Version
 1.00. We are researching this problem and will post new information
 here as it becomes available.


 76. Help Screen for Error 13 Has Incomplete Information

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist1.00 docerr
 Last Modified: 30-NOV-1989    ArticleIdent: Q50132

 The help screen for "Error 13: String constant exceeds line" says that
 the string does not have a closing quotation mark and that string
 constants must be contained in the same line.

 If a string is not contained in the same line, it still may have a
 closing quotation mark, it's just not on the same line as the opening
 quotation mark. A better explanation would be the following:

    A closing quote for the string was not found on the same line as
    the opening quote. A string must be contained on a single line.

 Microsoft has confirmed this to be a problem with QuickPascal Version
 1.00. We are researching this problem and will post new information
 here as it becomes available.


 77. QP1.00:<Find All> Does Not Exist When Searching in Help Window

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 21-MAR-1990    ArticleIdent: Q50473

 In QuickPascal Version 1.00, when performing a Search.Find in a help
 window, the <Find All> option is unavailable. This option is available
 when searching in a regular file window.

 This option is under review and is being considered for inclusion a
 future release of QuickPascal (QP).


 78. QuickPascal 1.00 PACKING.LST (3.5-Inch Version)

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 30-NOV-1989    ArticleIdent: Q51250

 The following information is from the packing list for the 3.5-inch
 version of Microsoft QuickPascal (R) Compiler, Version 1.00:

 Disk 1: Program/Setup/Utilities

 Files                  Description
 -----                  -----------

 QP.EXE                 Microsoft QuickPascal program development
                        environment.
 QPL.COM                QuickPascal command-line compiler.
 QPL.ERR                QuickPascal command-line compiler error
                        messages.
 PACKING.LST            Packing list (this file).
 SETUP.EXE              SETUP program -- installs QuickPascal.
 README.DOC             Directs you to README in Help.
 FIXSHIFT.COM           Fixes BIOS bug for certain Compaq (R) and other
                        keyboards.
 MOUSE.COM              Microsoft Mouse driver.
 MSHERC.COM             TSR -- supports Hercules (R) card graphics.
 QPMKKEY.EXE            Creates customized keyboard command files.

 SAMPLES\BIGHEAP.PAS    New versions of GetMem and FreeMem that can
                        allocate heap space in blocks larger than 65,520
                        bytes.

 SAMPLES\BIGMEM.PAS     BIGMEM.PAS uses the sample BigHeap unit.
 SAMPLES\MOUSE.PAS      Real mode mouse control routines; derived from
                        "Microsoft OS/2 Programmer's Reference," Chapter
                        3.
 SAMPLES\SORTDEMO.PAS   Graphically demonstrates six common sorting
                        algorithms
 SAMPLES\OBJECTS.PAS    Object-oriented demo.
 SAMPLES\CRLF.PAS       Normalizes all line endings of a text file to
                        CRLF.
 SAMPLES\GRDMEO.PAS     Demonstrates the QuickPascal graphics library.
                        It uses two additional units: menu and turtle.
 SAMPLES\MENU.PAS       Used by Grdemo.
 SAMPLES\TURTLE         Used by Grdemo (for Turtle graphics).
 BRIEF.KEY              Keyboard MAP files.
 EMACS.KEY                " "
 EPSILON.KEY              " "
 QP.KEY                   " "
 ME.KEY                   " "

 Disk 2: Microsoft QuickPascal Advisor/Microsoft QuickPascal Express

 Files                  Description
 -----                  -----------

 QP.HLP                 QuickPascal help files.
 QPENV.HLP                " "
 QPERR.HLP                " "
 QPGRAPH.HLP              " "
 NOTES.HLP                " "
 LEARN.EXE              Computer-Based Training file.
 QPCBT.CTX                " "
 QPCBT.SCN                " "
 QPCBT.SOB                " "
 LEARN.PIF              Computer-Based Training Windows PIF file.
 ATT6300.VID            Computer-Based Training additional display
                        drivers.
 CGASNOW.VID              " "
 ERICSSON.VID             " "
 HERC102.VID              " "
 HERC112.VID              " "

 Disk 3: Libraries

 Files                  Description
 -----                  -----------

 SYSTEM.QPU             System Unit.
 CRT.QPU                CRT Interface Unit.
 DOS.QPU                DOS Interface Unit.
 MSGRAPH.QPU            Graphics Interface Unit.
 MSGRUTIL.QPU           Graphics Support Unit.
 GRAPH.QPU              Graphics Support Unit.
 PRINTER.QPU            Printer Interface Unit.
 COURB.FON              Font files.
 ROMAN.FON                " "
 SCRIPT.FON               " "
 TMSRB.FON                " "
 HELVB.FON                " "
 MODERN.FON               " "


 79. Bad Expression in Debug Window Yields Incorrect Error Message

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | docerr
 Last Modified:  4-JAN-1990    ArticleIdent: Q51473

 If you enter a numeric value followed by a character in the debug
 window, you will get the error "Invalid end of line," which is
 incorrect. The error should read "Invalid expression."


 80. Error 73 Caused by Passing Incorrect Parameters

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | docerr
 Last Modified:  4-JAN-1990    ArticleIdent: Q51776

 QuickPascal's ERROR 73, which is defined as "Error in Statement," may
 be caused by passing different parameters than that which a function
 or procedure expects.

 As expected, the compiler highlights the call to the procedure or
 function and brings up the error message window. But if you select
 <Help> when given the ERROR 73 message, the QuickPascal environment
 gives "An undefined error occurred in the statement" as more
 information.

 The following code demonstrates this behavior:

 program errtest;

 procedure test;
 var i: integer;
 begin
      i := 3;
 end;

 begin
      test(3);
 end.

 The compiler highlights the call to test and brings up ERROR 73 on a
 pop-up window.


 81. OK to Redefine Predefined Functions and Procedures

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | S_PasCal
 Last Modified:  4-JAN-1990    ArticleIdent: Q51777

 If you define a function or procedure in your QuickPascal program
 which happens to have the same name as a run-time library routine, you
 will receive no error messages, and QuickPascal will accept your
 definition of the function instead of the run-time routine's
 definition.

 The following code demonstrates this behavior:

 program dupefunc;

 function sin (x: Real):Real;
 begin
    sin := 30.0;
 end;

 var x, y : Real;
 begin
    x := 7.0;
    y := sin(x);
    writeln('Sin of 7.0 returns: ', y);
 end.

 The program writes the following line to the screen upon execution:

 Sin of 7.0 returns: 30

 This is expected behavior for QuickPascal and also occurs in Pascal
 Version 4.00.


 82. How to Pass Functions and Procedures As Parameters

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified:  2-JAN-1990    ArticleIdent: Q51832

 It is possible to pass functions or procedures as parameters to other
 functions or procedures. To do this, you must declare a TYPE of that
 procedure or function and you must declare the procedure or function
 with long calls and returns. The following code demonstrates this:

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

 program passing(input, output);
 type
         Func = function(x : integer) : integer;
         Proc = procedure(x : integer);

 var
         x : integer;

 {$F+}

 function square(x : integer) : integer;
 begin
         square := x * x;
 end;

 procedure printline(x : integer);
 begin
         write('The square of ',x,' is ');
 end;

 {$F-}

 procedure trial(myfunc : Func ; myproc : Proc ; x : integer);
 var
         z : integer;
 begin
         myproc(x);
         z := myfunc(x);
         writeln(z);
 end;

 begin
         trial(square, printline, 5);
 end.

 Note the two types defined in the program: one called Func and the
 other called Proc. The Func type can be any function that takes an
 integer and returns an integer; the Proc type can be any procedure
 that takes an integer. If, for example, you have another procedure
 that takes a single integer, you can pass it with the same Proc type.

 Also note the {$F+} and {$F-} compiler directives. These compiler
 directives tell the compiler to generate long calls and returns.


 83. QuickPascal Cannot Trace Program with Pointers of Type OBJECT

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist1.00
 Last Modified:  6-MAR-1990    ArticleIdent: Q57291

 Tracing into a program with pointers of type OBJECT in QuickPascal
 Version 1.00 causes the system to hang at the line that follows the
 assignment of the pointer.

 Trace into the following program in the QuickPascal environment using
 F8. The system hangs at the line after the assignment of the pointer.
 The program runs correctly if you use F5 to run the program from
 within the environment or to run it from the DOS prompt outside the
 environment; the program hangs the machine only when tracing using F8.

 Code Sample
 --------------

      PROGRAM ObjectPointer;
      {$M+}

      TYPE
           obj = OBJECT
                 str : STRING
           END;

      VAR
           ptr : ^obj;

      BEGIN

           new (ptr);
           ptr^.str := 'Hello';
           writeln ('ptr^.str = ', ptr^.str);  { Will hang here.}

      END.

 Microsoft has confirmed this to be a problem with QuickPascal Version
 1.00. We are researching this problem and will post new information
 here as it becomes available.



 84. QuickPascal May Not Install in 3.x Box of OS/2 with HPFS

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 16-JAN-1990    ArticleIdent: Q57312

 QuickPascal may not install properly on a fixed disk if you are in the
 3.x box of OS/2 and your hard drive has the High Performance File
 System (HPFS) installed.

 The following are descriptions of problems that occur when running
 Setup:

 Case 1
 ------

 If you specify the destination drive to be one on which HPFS is
 installed, and if the current default drive is Drive A, QuickPascal
 will always try to use Drive B as the destination drive, unless the
 machine has no Drive B. In this case, QuickPascal will attempt to use
 Drive A as the destination drive, even though you are using A as the
 source drive.

 Case 2
 ------

 If the current default drive is Drive C and Drive C has HPFS
 installed, then QuickPascal will install all files in the root
 directory of Drive C (C:\), even if you specify C:\QP as the
 destination directory.

 To work around setup problems, use a manual installation procedure for
 QuickPascal.

 The following is the manual setup procedure:

 1. Copy all files from the distribution disks to a subdirectory on the
    hard drive.

 2. Invoke QuickPascal from the 3x box.

 3. Correctly set the environment paths from the Options in the
    QuickPascal menu.


 85. FEXPAND() May Return the Wrong Path in QuickPascal

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist1.00
 Last Modified: 16-JAN-1990    ArticleIdent: Q57519

 The QuickPascal Version 1.00 run-time library function FEXPAND() does
 not return the root directory as the directory name if a single
 backslash '\' is passed as a string. Instead, the function returns the
 current working directory.

 Microsoft has confirmed this to be a problem with Microsoft
 QuickPascal Version 1.00. We are researching this problem and will
 post new information here as it becomes available.

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

 PROGRAM findfile;

 USES  Dos;

 VAR
     full_path   : pathstr;
     dir         : DirStr;
     fname       : NameStr;
     exten       : ExtStr;

 BEGIN

     full_path := FExpand( '\' );
     FSplit( full_path, dir, fname, exten );
     Writeln( 'File found first in:' );
     Writeln( 'Drive/directory : ', dir );
     Writeln( 'File name       : ', fname );
     Writeln( 'Extension       : ', exten );

 END.

 The current workaround for this problem is to pass in '\.\' instead of
 '\'. This procedure will return the root directory.



 86. Syntax Charts for Pascal Program Structure -- Declarations

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | s_pascal
 Last Modified: 21-JAN-1990    ArticleIdent: Q57556

 A block in QuickPascal Version 1.00 is part of a procedure or function
 declaration, or a program or unit. A block is made up of declarations
 and statements, as shown below:

                   +------------------+       +----------------+
      block ------>| declaration part |------>| statement part |
                   +------------------+       +----------------+

 The declaration part is made up of labels, constants, types,
 variables, and procedure/function declarations.  All of these
 declarations are LOCAL to the block.

 Example
 -------

 declaration part -----+--------------------------------------+-->
                    ^  |                                   ^  |
                    |  +--->[ LABEL declaration part ]-----+  |
                    |  |                                   |  |
                    |  +--->[ CONSTANT declaration part ]--+  |
                    |  |                                   |  |
                    |  +--->[ TYPE declaration part ]------+  |
                    |  |                                   |  |
                    |  +--->[ VARIABLE declaration part ]--+  |
                    |  |                                   |  |
                    |  +--->[ PROC/FUNC declaration part ]-+  |
                    |                                         |
                    +-----------------------------------------+

 Labels declared in the LABEL declaration part mark statements in the
 corresponding statement part. Each label marks only one statement.

 Example
 -------

 label
 declaration part ---->{ LABEL }----->[ label ]--+--->{ ; }
                                  ^              |
                                  |              |
                                  +----{ , }<----+

 Digits or identifiers may be used for labels. Digits must be in the
 range of 0-9999.

 Example
 -------

 constant
 declaration part --->{ CONST }----+--->[ const. decl. ]-----+--->
                                ^  |                       ^ |
                                |  |                       | |
                                |  +->[ typed const. decl]-+ |
                                |                            |
                                +----------------------------+
 type
 declaration part ---->{ TYPE }---->[ type decl. ]---+--->
                                ^                    |
                                |                    |
                                +--------------------+

 variable
 declaration part ---->{ VAR }----->[ var decl. ]--+--->
                                ^                  |
                                |                  |
                                +------------------+

 procedure/function
 declaration part --------+--->[ procedure decl. ]-----+--->
                       ^  |                         ^  |
                       |  |                         |  |
                       |  +---->[ function decl ]---+  |
                       |                               |
                       +-------------------------------+

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

 PROGRAM TEST(output);

 LABEL     x1;

 CONST     NUM_GOMERS = 1000;

 TYPE      ARRAY_TYPE = array [1..10] of char;

 VAR       char_array : ARRAY_TYPE;
                    i : integer;

 FUNCTION Foo( spud : char ):integer;

      VAR    x   : integer;

 BEGIN

      x := 5;
      writeln('This should print.');
      Foo := x;

 END;

 BEGIN
      i := 0;

      goto x1;

      if (i < 2) then
        begin
           writeln('this should not print.');
           x1:  i := foo( char_array[1] );
        end;
 END.


 87. Documentation Error in HORIZON.PAS

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | docerr
 Last Modified: 23-JAN-1990    ArticleIdent: Q57860

 The sample program HORIZON.PAS on Page 189 of the "Microsoft
 QuickPascal - Pascal By Example" and the online help example program
 in "Pascal By Example" does not cycle through the 256 colors. The
 following lines are incorrect:

    rainbow[col + 192] := Red OR NOT gray;
    rainbow[col + 192 + 256] := Red OR NOT gray;

 To correct the problem, change "OR" to "AND," as follows:

    rainbow[col + 192] := Red AND NOT gray;
    rainbow[col + 192 + 256] := Red AND NOT gray;

 The correction allows the program to cycle through the 256 colors.


 88. _RemapAllPalette May Fail on VGA

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist1.00
 Last Modified:  5-FEB-1990    ArticleIdent: Q57892

 The QuickPascal run-time graphics function, _RemapAllPalette, may fail
 on a VGA if a color that is out-of-range is given as its argument.

 For a value to be a legal color on a VGA, it must be of the binary
 form 0000000000XXXXXX00XXXXXX00XXXXXX. If _RemapAllPalette is given a
 color or an array of colors as an argument, and if any of the colors
 in the array are illegal, the function will terminate execution and
 return. This is not quite consistent with the way it behaves on EGAs.

 This problem is evident in the HORIZON.PAS program located on Page 189
 of "Microsoft QuickPascal - Pascal by Example," and also available
 from the online help by selecting the following from the HELP menu:

    Contents.Pascal by Example Programs.HORIZON.PAS

 A workaround can be achieved by masking each of the values in the
 array with the hex value $003F3F3F. This forces each color back into
 the "legal" range.

 Microsoft has confirmed this to be a problem with the _RemapAllPalette
 function in QuickPascal Version 1.00. We are researching this problem
 and will post new information here as it becomes available.


 89. Different Results When Running Program from DOS Prompt

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified:  5-MAR-1990    ArticleIdent: Q58109

 Different results may be obtained when running a program from within
 the QuickPascal environment and when running the same executable from
 the DOS prompt.

 The QuickPascal environment may appear to automatically initializes
 all global variables and arrays to 0 (although this behavior is not
 guaranteed); in the case of an array of type BOOLEAN, all entries are
 initialized to FALSE. However, this behavior does not occur after
 exiting the environment and running the same executable from the DOS
 prompt. When running a program from the DOS prompt, any uninitialized
 variables will consistently be undefined.

 Also note that this automatic initialization only applies to global
 variables. Any variable or array declared locally within a procedure
 or function must be initialized, whether running the program from
 within the environment or from the DOS prompt. Otherwise, its value
 (or the value of its elements, in the case of an array) will be
 undefined.

 This is expected behavior. The general rule to follow when writing
 good code is to initialize ALL variables and arrays before use to
 avoid inconsistent results. Otherwise, their contents may be
 undefined, and the output of your program will be unpredictable.

 The following code demonstrates this situation:

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

 PROGRAM bogus_code;

 VAR
         x : integer;
         P : array [1..10] of integer;   { Array declared globally }

 PROCEDURE call;

         VAR

         A : array [1..10] of integer;   { Array declared locally }

 BEGIN

  { Uncomment this section to initialize array A }

    {x := 1;
     while x <= 10 do
         BEGIN
          A[x] := 0;
          x := x+1;
         END;}

     x := 1;

     while x <= 10 do
         BEGIN
          write( A[x], ' ' );  { Print contents of array A }
          x := x + 1;
         END;

     writeln;

 END; { call }

 BEGIN   { main }

         call;

  { Uncomment this section to initialize array P }

    {x := 1;
     while x <= 10 do
         BEGIN
          P[x] := 0;
          x := x+1;
         END;}

     x := 1;

     while x <= 10 do
         BEGIN
          write( P[x], ' ' );  { Print contents of array P }
          x := x + 1;
         END;

     writeln;

 END.

 Compile the above program and run it from within the QuickPascal
 environment using F5. It will print random numbers from array A, while
 array P will output all 0's (zeros), even though it has not been
 explicitly initialized. Then exit the environment and run the program
 from the DOS prompt. Both arrays will then output random numbers. To
 achieve consistent results from both within the QuickPascal
 environment and from the DOS prompt, uncomment the two initialization
 routines above.

 Also note that if the Options.Compiler.Debug_Information switch is
 disabled in the QuickPascal environment, variables and arrays will not
 be initialized, either from within the environment or from the DOS
 prompt.


 90. Path Incorrectly Stated in "Up and Running"

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | docerr
 Last Modified: 26-FEB-1990    ArticleIdent: Q58652

 On Page 7, 11, and 15 of the "Microsoft QuickPascal -- Up and Running"
 manual, the default paths for the file types are incorrectly stated. The
 correct default paths for the file types are shown below:

    Path                      File Type
    ----                      ---------

    C:\QP                     Executable (.EXE)
    C:\QP                     Unit (.QPU)
    C:\QP\HLP                 Help (.HLP)


 91. Using the Undocumented SWAP Option When Invoking QuickPascal

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | docerr
 Last Modified: 26-FEB-1990    ArticleIdent: Q58782

 When compiling a very large program with multiple large modules in
 QuickPascal, a dialog box with the following message may appear:

    Error 1:  Out of memory

 Clicking on the <help> switch of the dialog box reveals the following
 explanation:

    There was not enough memory for compiling. Either the program was
    too big or available memory was insufficient.

    - Split a large program into smaller parts. Put functions and
      procedures into a unit. Allocate variables dynamically rather
      than statically.

    - Close unneeded windows before compiling.

    - Reinvoke QP, swapping to disk or to expanded memory.

         To swap to disk:               QP /SWAP:DISK
         To swap to expanded memory:    QP /SWAP:EMS

 The SWAP option is not documented. The out-of-memory problem may be
 caused by using a large number of units, especially if you are using
 MSGRAPH.QPU or GRAPH.QPU. QuickPascal tries to load ALL of the units
 on the USES line into memory before deciding which parts of these
 units it needs to use. If you have large, memory-intensive units, this
 uses up memory very fast and you may get the "out-of-memory" error
 message even though the resulting executable may be very small.

 However, using SWAP may not be the automatic solution for the
 out-of-memory problem. SWAP does NOT cause these units to be loaded
 into the swap area. When SWAP has been invoked using one of the above
 commands, QuickPascal creates a 1 MB swap file on disk (or in expanded
 memory) to use for swapping in and out some of the QuickPascal
 environment elements. (To use SWAP, you must have at least 1 MB of
 free disk space, or you must be using an expanded memory module.)

 Therefore, reinvoking QuickPascal with the SWAP option still may not
 cure the "out-of-memory" error message.

 At load time, the initial swap area is set aside, and part of the user
 interface (environment) code is loaded into it. The amount of free
 memory does not change after that; that is, HEAP size remains a
 constant. A predetermined amount of code is swapped in and out of the
 swap area in single chunks as needed.

 This swapping area is not used at all by QuickPascal for any of the
 units or the program being compiled, but it should help when making
 room for a very large program that does not use any of the graphics
 units.


 92. QP Help: Error: Out of Memory

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | s_error
 Last Modified: 15-APR-1990    ArticleIdent: Q60513

 The following information is from the QuickPascal Version 1.00
 QPERR.HLP help file:

    Error 1: Out of memory

 There was not enough memory for compiling. Either the program was too
 big or available memory was insufficient.

 - Split a large program into smaller parts. Put functions and
   procedures into a unit. Allocate variables dynamically rather than
   statically.

 - Close unneeded windows before compiling.

 - Reinvoke QP, swapping to disk or to expanded memory.

      To swap to disk:               QP /SWAP:DISK
      To swap to expanded memory:    QP /SWAP:EMS


 93. QP Help: Error: Line Too Long

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | s_error
 Last Modified: 15-APR-1990    ArticleIdent: Q60514

 The following information is from the QuickPascal Version 1.00
 QPERR.HLP help file:

    Error 10: Line too long

 The line at the cursor exceeds QuickPascal's maximum line length of
 128 characters.

 Possible methods for shortening the line include:

    - Breaking a complex expression into smaller parts
    - Reducing the length of variable and constant names
    - Deleting any trailing blanks or tabs on the line
    - Creating long strings with the plus (+) operator


 94. QP Help: Error: Field or Method Already Defined

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | s_error
 Last Modified: 15-APR-1990    ArticleIdent: Q60515

 The following information is from the QuickPascal Version 1.00
 QPERR.HLP help file:

    Error 102: Field or method already defined

 This name has already been used to define a field or method.

 Give the field or method a different name, or rename the previously
 defined field or method that uses the same name.


 95. QP Help: Error: Invalid QPU File

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | s_error
 Last Modified: 15-APR-1990    ArticleIdent: Q60516

 The following information is from the QuickPascal Version 1.00
 QPERR.HLP help file:

    Error 103: Invalid QPU file

 The USES statement refers to a file that is not a valid .QPU file.
 Either the file does not exist, or it exists but is not a compiled
 QuickPascal unit.

 Check to make sure the file exists and is spelled correctly. If the
 problem persists, delete the .QPU file and recompile the unit from its
 original source code.


 96. QP Help: Error: Duplicate Unit Name

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | s_error
 Last Modified: 15-APR-1990    ArticleIdent: Q60517

 The following information is from the QuickPascal Version 1.00
 QPERR.HLP help file:

    Error 104: Duplicate unit name

 The same unit has been specified more than once in the USES statement.

 Remove the duplicate references.


 97. QP Help: Error: Circular Unit Reference

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | s_error
 Last Modified: 15-APR-1990    ArticleIdent: Q60518

 The following information is from the QuickPascal Version 1.00
 QPERR.HLP help file:

    Error 105: Circular unit reference

 A circular reference was made in the interface section of a unit.

 Circular references are allowed only in the implementation sections of
 units.


 98. QP Help: Error: Error in Real Constant

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | s_error
 Last Modified: 15-APR-1990    ArticleIdent: Q60519

 The following information is from the QuickPascal Version 1.00
 QPERR.HLP help file:

    Error 106: Error in real constant

 This constant does not conform to the syntax for a real number. Change
 the constant to the correct syntax.


 99. QP Help: Error: Coprocessor Required

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | s_error
 Last Modified: 15-APR-1990    ArticleIdent: Q60520

 The following information is from the QuickPascal Version 1.00
 QPERR.HLP help file:

    Error 107: Coprocessor required

 QuickPascal requires a math coprocessor to perform this operation.
 Unless your computer uses math chips from the Intel 80x87 family, you
 cannot specify the {$N+} compiler directive or the use of a
 coprocessor in the Compiler dialog box under the Options menu.


 100. QP Help: Error: Too Many Nested Conditional Directives

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | s_error
 Last Modified: 15-APR-1990    ArticleIdent: Q60521

 The following information is from the QuickPascal Version 1.00
 QPERR.HLP help file:

    Error 108: Too many nested conditional directives

 A series of conditional statements is nested too deeply.

 Break the construct into smaller pieces that do not require such deep
 nesting.


 101. QP Help: Error: Misplaced Directive

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | s_error
 Last Modified: 15-APR-1990    ArticleIdent: Q60522

 The following information is from the QuickPascal Version 1.00
 QPERR.HLP help file:

    Error 109: Misplaced directive

 This directive is out of sequence or located in the wrong part of the
 program. Move or delete the directive. For example, an $ENDIF
 directive must appear after an $IFxx directive.


 102. QP Help: Error: $ENDIF Directive Missing

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | s_error
 Last Modified: 15-APR-1990    ArticleIdent: Q60523

 The following information is from the QuickPascal Version 1.00
 QPERR.HLP help file:

    Error 110: $ENDIF directive missing

 The $IFxx compiler directive requires an $ENDIF directive to terminate
 the $IFxx block.

 Insert the $ENDIF directive at the appropriate location.


 103. QP Help: Error: Too Many Conditional Symbols

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | s_error
 Last Modified: 15-APR-1990    ArticleIdent: Q60524

 The following information is from the QuickPascal Version 1.00
 QPERR.HLP help file:

    Error 111: Too many conditional symbols

 The number of defined symbols exceeded the maximum in QuickPascal.

 Use {$UNDEF} to undefine some symbols or to reduce the number of
 conditional symbols. Use a UNIT or included file, if necessary.


 104. QP Help: Error: Error in Integer Constant

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | s_error
 Last Modified: 15-APR-1990    ArticleIdent: Q60525

 The following information is from the QuickPascal Version 1.00
 QPERR.HLP help file:

    Error 11: Error in integer constant

 The integer constant at the cursor was not in the range -2147483647 to
 2147483648.

 Check that the number is an integer within range.

 This error occurs when specifying the lowest value in the LongInt
 range, -2147483648. Use First( LongInt ) to represent this value.


 105. QP Help: Error: Header Does Not Match Previous Declaration

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | s_error
 Last Modified: 15-APR-1990    ArticleIdent: Q60526

 The following information is from the QuickPascal Version 1.00
 QPERR.HLP help file:

    Error 112: Header does not match previous declaration

 This procedure or function header does not match its original
 declaration.

 A procedure or function's first declaration takes precedence over a
 subsequent header. The headers must match exactly. Change the
 incorrect header to match the correct one. Cutting and pasting ensures
 a perfect match.


 106. QP Help: Error: Invalid Qualification

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | s_error
 Last Modified: 15-APR-1990    ArticleIdent: Q60527

 The following information is from the QuickPascal Version 1.00
 QPERR.HLP help file:

    Error 113: Invalid qualification

 An error occurred in the identifier name used as a qualifier, or the
 name given to the qualifier is not available within the current scope.

 Check the spelling of the qualifying name. Make sure that any needed
 units are specified in the USES statement.


 107. QP Help: Error: Too Many Parameters

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | s_error
 Last Modified: 15-APR-1990    ArticleIdent: Q60528

 The following information is from the QuickPascal Version 1.00
 QPERR.HLP help file:

    Error 114: Too many parameters

 The size in bytes of passed parameters exceeded 64K.


 108. QP Help: Error: Class Must Be Defined at Global Level

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | s_error
 Last Modified: 15-APR-1990    ArticleIdent: Q60529

 The following information is from the QuickPascal Version 1.00
 QPERR.HLP help file:

    Error 115: Class must be defined at global level

 A class has been defined locally.

 Classes must be defined at the beginning of the program (or at the
 beginning of either the INTERFACE or IMPLEMENTATION sections of a
 unit) in order to make them global definitions.

 Move the class definition up with the global level declarations.


 109. QP Help: Error: Class Must Be Defined in Type Definition

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | s_error
 Last Modified: 15-APR-1990    ArticleIdent: Q60530

 The following information is from the QuickPascal Version 1.00
 QPERR.HLP help file:

    Error 116: Class must be defined in type definition

 Define a class within a TYPE declaration.


 110. QP Help: Error: Invalid Procedure or Function Reference

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | s_error
 Last Modified: 15-APR-1990    ArticleIdent: Q60531

 The following information is from the QuickPascal Version 1.00
 QPERR.HLP help file:

    Error 117: Invalid procedure or function reference

 An attempt was made to assign a near procedure to a procedure
 variable.

 Procedure variables must refer to far procedures.

 To correct the problem:

 - Turn on the Far Calls directive under the Compiler option in the
    Options menu.

 - Place the procedure declaration between the {$F+} and {$F-}
   directives.


 111. QP Help: Error: Procedure or Function Variable Expected

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | s_error
 Last Modified: 15-APR-1990    ArticleIdent: Q60532

 The following information is from the QuickPascal Version 1.00
 QPERR.HLP help file:

    Error 118: Procedure or function variable expected

 The variable must be a procedural-type variable.

 Check to see that you followed the correct syntax for declaring and
 typing variables within a parameter list. Remember that returned
 variables require the VAR keyword.


 112. QP Help: Error: Object Type Expected

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | s_error
 Last Modified: 15-APR-1990    ArticleIdent: Q60567

 The following information is from the QuickPascal Version 1.00
 QPERR.HLP help file:

    Error 119: Object type expected

 An object type was expected.


 113. QP Help: Error: Object Must Be Defined at Global Level

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | s_error
 Last Modified: 15-APR-1990    ArticleIdent: Q60568

 The following information is from the QuickPascal Version 1.00
 QPERR.HLP help file:

    Error 120: Object must be defined at global level

 An object has been defined at a level other than a global level.

 Move the definition up to the same level as global constants and
 variables.


 114. QP Help: Error: OBJECT Must Be Defined in Type Definition

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | s_error
 Last Modified: 15-APR-1990    ArticleIdent: Q60569

 The following information is from the QuickPascal Version 1.00
 QPERR.HLP help file:

    Error 121: OBJECT must be defined in type definition

 An occurrence of "OBJECT" has been found outside of a type
 declaration. The keyword "OBJECT" is reserved for declaring class
 types.

    MyClass = (OBJECT)
        the_data: Integer;
        Procedure MyClass.MyMethod;
    END;


 115. QP Help: Error: Error in Character Constant

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | s_error
 Last Modified: 15-APR-1990    ArticleIdent: Q60570

 The following information is from the QuickPascal Version 1.00
 QPERR.HLP help file:

    Error 12: Error in character constant

 The character constant at the cursor contains an error.

 Check that the value assigned to the constant is a character data type
 (not an integer, real, string, or other data type).


 116. QP Help: Error: Invalid Class Type

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | s_error
 Last Modified: 15-APR-1990    ArticleIdent: Q60571

 The following information is from the QuickPascal Version 1.00
 QPERR.HLP help file:

    Error 122: Invalid class type

 The name of a defined object was invalid.

 The name of an object cannot be the same as a parent name. For
 example, the following will cause this error:

    TYPE
        my_name = OBJECT( my_name );


 117. QP Help: Error: Class Table Overflow

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | s_error
 Last Modified: 15-APR-1990    ArticleIdent: Q60572

 The following information is from the QuickPascal Version 1.00
 QPERR.HLP help file:

    Error 123: Class table overflow

 The number of classes that can be stored in the class table has been
 exceeded.

 Reduce the number of classes to continue.

 You may be able to decrease the number of classes by using instances
 of existing classes.


 118. QP Help: Error: Syntax Error

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | s_error
 Last Modified: 15-APR-1990    ArticleIdent: Q60573

 The following information is from the QuickPascal Version 1.00
 QPERR.HLP help file:

    Error 124: Syntax error

 The statement is not formed correctly.


 119. QP Help: Error: This Method Has No Parent

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | s_error
 Last Modified: 15-APR-1990    ArticleIdent: Q60574

 The following information is from the QuickPascal Version 1.00
 QPERR.HLP help file:

    Error 125: This method has no parent

 INHERITED has been applied to a method that has no parent. Either
 create a parent class with a method to inherit, or do not use the
 INHERITED keyword.


 120. QP Help: Error: Type of Expression Must Be POINTER

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | s_error
 Last Modified: 15-APR-1990    ArticleIdent: Q60575

 The following information is from the QuickPascal Version 1.00
 QPERR.HLP help file:

    Error 126: Type of expression must be POINTER

 The expression in the statement must be of a POINTER type.


 121. QP Help: Error: Invalid Variable Reference

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | s_error
 Last Modified: 15-APR-1990    ArticleIdent: Q60576

 The following information is from the QuickPascal Version 1.00
 QPERR.HLP help file:

    Error 127: Invalid variable reference

 A constant, expression, or function has been applied to a procedure
 expecting a VAR parameter. Substitute a variable to continue.


 122. QP Help: Error: Symbol Table Overflow

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | s_error
 Last Modified: 15-APR-1990    ArticleIdent: Q60577

 The following information is from the QuickPascal Version 1.00
 QPERR.HLP help file:

    Error 128: Symbol table overflow

 QuickPascal can only support up to 64K of declared symbols in a unit
 or program.

 Avoid symbol table overflow by moving some declarations into another
 unit.


 123. QP Help: Error: Too Many Imported Units

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | s_error
 Last Modified: 15-APR-1990    ArticleIdent: Q60578

 The following information is from the QuickPascal Version 1.00
 QPERR.HLP help file:

    Error 129: Too many imported units

 QuickPascal allows up to 81 units to be included in a program. Combine
 procedures and functions into existing units to reduce the number of
 total units.


 124. QP Help: Error: Code Cannot Exceed 64K Bytes

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | s_error
 Last Modified: 15-APR-1990    ArticleIdent: Q60579

 The following information is from the QuickPascal Version 1.00
 QPERR.HLP help file:

    Error 130: Code cannot exceed 64K bytes

 The total size of the code cannot exceed 64K bytes. Split the program
 into several units to continue.


 125. QP Help: Error: Invalid Real Operation

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | s_error
 Last Modified: 15-APR-1990    ArticleIdent: Q60580

 The following information is from the QuickPascal Version 1.00
 QPERR.HLP help file:

    Error 131: Invalid real operation

 An operation on two real types in this statement resulted in an
 invalid floating-point operation. Either an overflow occurred or an
 attempt was made to divide by zero.


 126. QP Help: Error: String Constant Exceeds Line

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | s_error
 Last Modified: 15-APR-1990    ArticleIdent: Q60581

 The following information is from the QuickPascal Version 1.00
 QPERR.HLP help file:

    Error 13: String constant exceeds line

 The string is missing a closing quote. A string must be contained on a
 single line.


 127. QP Help: Error: Real Overflow

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | s_error
 Last Modified: 15-APR-1990    ArticleIdent: Q60582

 The following information is from the QuickPascal Version 1.00
 QPERR.HLP help file:

    Error 132: Real overflow

 A floating-point operation produced an overflow. Do not exceed the
 maximum allowed value of a real type.


 128. QP Help: Error: Real Underflow

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | s_error
 Last Modified: 15-APR-1990    ArticleIdent: Q60583

 The following information is from the QuickPascal Version 1.00
 QPERR.HLP help file:

    Error 133: Real underflow

 A floating-point operation produced an underflow. This error only
 occurs if you are using the 8087 numeric coprocessor with a control
 word that unmasks underflow exceptions.


 129. QP Help: Error: Undefined External

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | s_error
 Last Modified: 15-APR-1990    ArticleIdent: Q60584

 The following information is from the QuickPascal Version 1.00
 QPERR.HLP help file:

    Error 134: Undefined external

 A subprogram has been declared external, but it was not defined by
 any of the .OBJ files linked in with the program.


 130. QP Help: Error: Too Many Object File Names

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | s_error filenames
 Last Modified: 15-APR-1990    ArticleIdent: Q60585

 The following information is from the QuickPascal Version 1.00
 QPERR.HLP help file:

    Error 135: Too many object file names

 Too many .OBJ files have been linked in. Reduce the number of object
 files to link with the program.


 131. QP Help: Error: Invalid Object File

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | s_error
 Last Modified: 15-APR-1990    ArticleIdent: Q60586

 The following information is from the QuickPascal Version 1.00
 QPERR.HLP help file:

    Error 136: Invalid object file

 The object file that was to be linked contains invalid information.
 Verify that the file actually is an .OBJ file.


 132. QP Help: Error: Object File Too Large

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | s_error
 Last Modified: 19-APR-1990    ArticleIdent: Q60652

 The following information is from the QuickPascal Version 1.00
 QPERR.HLP help file:

    Error 137: Object file too large

 The object file that was to be linked is too large. .OBJ files cannot
 exceed 64K in length.


 133. QP Help: Error: Invalid Segment Definition

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | s_error
 Last Modified: 19-APR-1990    ArticleIdent: Q60653

 The following information is from the QuickPascal Version 1.00
 QPERR.HLP help file:

    Error 138: Invalid segment definition

 An .OBJ file being read in by the {$L} directive contained one of the
 following:

 - The AT combine type

 - Two code segments, one named CODE and one named CSEG

 - A data or code segment exactly 64K in size


 134. QP Help: Error: Invalid Segment Name

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | s_error
 Last Modified: 19-APR-1990    ArticleIdent: Q60654

 The following information is from the QuickPascal Version 1.00
 QPERR.HLP help file:

    Error 139: Invalid segment name

 A segment had an invalid name.

 A data segment may be named DSEG or DATA. A code segment may be named
 CSEG or CODE. There can be only one code and one data segment.


 135. QP Help: Error: Code Segment Too Large

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | s_error
 Last Modified: 19-APR-1990    ArticleIdent: Q60655

 The following information is from the QuickPascal Version 1.00
 QPERR.HLP help file:

    Error 140: Code segment too large

 The code segment is too large. Code segments may not exceed 64K in
 length. Reduce the size of the segment by splitting the program into
 several units.


 136. QP Help: Error: Invalid PUBLIC Definition

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | s_error
 Last Modified: 19-APR-1990    ArticleIdent: Q60656

 The following information is from the QuickPascal Version 1.00
 QPERR.HLP help file:

    Error 141: Invalid PUBLIC definition

 Error 141 occurs when loading .OBJ files with {$L <name>}.

 A symbol declared as PUBLIC in the .OBJ file is already in the symbol
 table from a different definition. A name collision has occurred.

 Change one of the names.


 137. QP Help: Error: Unexpected End of File

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | s_error
 Last Modified: 19-APR-1990    ArticleIdent: Q60657

 The following information is from the QuickPascal Version 1.00
 QPERR.HLP help file:

    Error 14: Unexpected end of file

 QuickPascal encountered an end-of-file where one was not expected
 (possibly in the middle of your program code).

 Check that you remembered the END statement in your source code.
 Alternately, remove any unintentional nonprinting characters at the
 cursor with the DEL key, or retype the entire line.


 138. QP Help: Error: Invalid EXTRN Definition

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | s_error
 Last Modified: 19-APR-1990    ArticleIdent: Q60658

 The following information is from the QuickPascal Version 1.00
 QPERR.HLP help file:

    Error 142: Invalid EXTRN definition

 Error 142 occurs when loading .OBJ files with {$L <name>}.

 The .OBJ file contains an EXTRN directive that refers to something
 other than a procedure, function, data item, or typed constant. An
 EXTRN may not refer to a type, simple constant, absolute variable, or
 inline procedure or function.


 139. QP Help: Error: Too Many EXTRNs

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | s_error
 Last Modified: 19-APR-1990    ArticleIdent: Q60659

 The following information is from the QuickPascal Version 1.00
 QPERR.HLP help file:

    Error 143: Too many EXTRNs

 Error 143 occurs when loading .OBJ files with {$L <name>}.

 An .OBJ file exceeded the QuickPascal limit of 512 EXTRN definitions
 per .OBJ file.


 140. QP Help: Error: Invalid Fixup

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | s_error
 Last Modified: 19-APR-1990    ArticleIdent: Q60660

 The following information is from the QuickPascal Version 1.00
 QPERR.HLP help file:

    Error 144: Invalid fixup

 Error 144 occurs when loading .OBJ files with {$L <name>}.

 An .OBJ file may not contain fixup records on byte values or fixups in
 the data segment. Such fixups are likely to occur if data is
 initialized to point to code. An .OBJ file may not contain initialized
 data.


 141. QP Help: Error: Too Many Opened Files

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | s_error
 Last Modified: 19-APR-1990    ArticleIdent: Q60661

 The following information is from the QuickPascal Version 1.00
 QPERR.HLP help file:

    Error 145: Too many opened files

 Compilation has exceeded the number of available DOS file handles.

 File handles are taken up by used units and by files included with the
 {$I} directive. Reduce the number of files in a single compilation, or
 increase the number of available handles by putting the following in
 CONFIG.SYS:

    FILES=20

 TSR (terminate-and-stay-resident) programs may use up file handles.
 Remove resident software, then recompile.


 142. QP Help: Error: Too Many Variables

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | s_error
 Last Modified: 19-APR-1990    ArticleIdent: Q60662

 The following information is from the QuickPascal Version 1.00
 QPERR.HLP help file:

    Error 146: Too many variables

 Storage size of all variables exceeded the capacity of the data
 segment.

 Variables and typed constants are stored in the data segment along
 with program data. The data segment may not exceed 64K.

 Use dynamic allocation (New or GetMem) to place data on the heap.


 143. QP Help: Error: Directive Must Be At Top of Program

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | s_error
 Last Modified: 19-APR-1990    ArticleIdent: Q60663

 The following information is from the QuickPascal Version 1.00
 QPERR.HLP help file:

    Error 147: Directive must be at top of program

 A global compiler directive was located after the beginning of the
 declaration of a program or unit.

 Global compiler directives must precede the implementation section in
 a unit. In a program, they must precede the first declaration,
 appearing before any CONST, TYPE, VAR, PROCEDURE, or FUNCTION. Global
 compiler directives are usually located immediately after any USES
 statements.


 144. QP Help: Error: Invalid Directive

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | s_error
 Last Modified: 19-APR-1990    ArticleIdent: Q60664

 The following information is from the QuickPascal Version 1.00
 QPERR.HLP help file:

    Error 15: Invalid directive

 The directive at the cursor is not a valid QuickPascal compiler
 directive.

 Verify that the directive uses the correct syntax (see the Directives
 entry in the Contents help screen).


 145. QP Help: Error: Invalid Assignment

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | s_error
 Last Modified: 19-APR-1990    ArticleIdent: Q60665

 The following information is from the QuickPascal Version 1.00
 QPERR.HLP help file:

    Error 148: Invalid assignment

 An assignment was made to an invalid type.

 Variables of type FILE and Text cannot be assigned to directly.


 146. QP Help: Error: Set Type Out of Range

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | s_error
 Last Modified: 19-APR-1990    ArticleIdent: Q60666

 The following information is from the QuickPascal Version 1.00
 QPERR.HLP help file:

    Error 149: Set type out of range

 The base type of a set exceeded the limit of a set.

 A set may have only 256 elements. Its base type must be a subrange
 within 0..255, or an enumerated type with no more than 256 values.
 Base types of ShortInt, Integer, LongInt, or Word are not permitted.


 147. QP Help: Error: Index Out of Range

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | s_error
 Last Modified: 19-APR-1990    ArticleIdent: Q60667

 The following information is from the QuickPascal Version 1.00
 QPERR.HLP help file:

    Error 150: Index out of range

 The index of an array variable declaration specified an invalid number
 of elements.

 The range of the index type of an array determines the number of
 elements in the array. Using a LongInt subrange as an array index will
 cause this error. Each array must fit within a single 64K segment. An
 array declared with this index range would exceed the maximum size for
 an array, no matter what type of element.


 148. QP Help: Error: Object Variable Expected in Member Function

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | s_error
 Last Modified: 19-APR-1990    ArticleIdent: Q60668

 The following information is from the QuickPascal Version 1.00
 QPERR.HLP help file:

    Error 151: Object variable expected in Member function

 The variable passed as the first argument to the Member function was
 not an object.


 149. QP Help: Error: Object Type Expected in Member Function

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | s_error
 Last Modified: 19-APR-1990    ArticleIdent: Q60669

 The following information is from the QuickPascal Version 1.00
 QPERR.HLP help file:

    Error 152: Object type expected in Member function

 The type passed as the second argument to the Member function was not
 a class.


 150. QP Help: Error: Expression Too Complicated

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | s_error
 Last Modified: 19-APR-1990    ArticleIdent: Q60670

 The following information is from the QuickPascal Version 1.00
 QPERR.HLP help file:

    Error 153: Expression too complicated

 An expression contains too many terms.

 Break up the complex expression into simpler expressions.


 151. QP Help: Error: Line Information Table Overflow

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | s_error
 Last Modified: 19-APR-1990    ArticleIdent: Q60671

 The following information is from the QuickPascal Version 1.00
 QPERR.HLP help file:

    Error 155: Line information table overflow

 The storage capacity for debug information was exceeded.

 The QuickPascal debugger can keep track of up to 16K source lines.

 Turn off the debugger with the {$D-} directive, or compile some source
 files without debugger information.


 152. QP Help: Error: Fixup Table Overflow

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | s_error
 Last Modified: 19-APR-1990    ArticleIdent: Q60787

 The following information is from the QuickPascal Version 1.00
 QPERR.HLP help file:

    Error 156: Fixup table overflow

 A program may only have 16K fixups.


 153. QP Help: Error: Source Table Overflow

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | s_error
 Last Modified: 19-APR-1990    ArticleIdent: Q60788

 The following information is from the QuickPascal Version 1.00
 QPERR.HLP help file:

    Error 157: Source table overflow

 The storage capacity for source file names was exceeded.

 QuickPascal allows a maximum of 2K of memory to keep track of the
 names of source files used in a program.

 Combine some files, or rename files with shorter names.


 154. QP Help: Error: Unit Expected

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | s_error
 Last Modified: 19-APR-1990    ArticleIdent: Q60789

 The following information is from the QuickPascal Version 1.00
 QPERR.HLP help file:

    Error 158: Unit expected

 A USES clause in a program called for a file that did not contain a
 UNIT heading.

 A used file must begin with a heading:

    UNIT <identifier>;


 155. QP Help: Error: End of File Expected

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | s_error
 Last Modified: 19-APR-1990    ArticleIdent: Q60790

 The following information is from the QuickPascal Version 1.00
 QPERR.HLP help file:

    Error 16: End of file expected

 QuickPascal expects an end-of-file at the cursor location.

 Move or delete everything after the END statement.


 156. QP Help: Error: Unsatisfied Forward Name Reference

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | s_error
 Last Modified: 19-APR-1990    ArticleIdent: Q60791

 The following information is from the QuickPascal Version 1.00
 QPERR.HLP help file:

    Error 159: Unsatisfied forward name reference

 A type declaration was used but never defined.


 157. QP Help: Error: Invalid Fixup in Iterated Data

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | s_error
 Last Modified: 19-APR-1990    ArticleIdent: Q60792

 The following information is from the QuickPascal Version 1.00
 QPERR.HLP help file:

    Error 160: Invalid fixup in iterated data

 A fixup cannot occur in an iterated data record.

 Check the assembly files for a relocatable reference inside a DUP
 record.


 158. QP Help: Error: Include Files Not Allowed Here

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | s_error
 Last Modified: 19-APR-1990    ArticleIdent: Q60793

 The following information is from the QuickPascal Version 1.00
 QPERR.HLP help file:

    Error 161: Include files not allowed here

 A file was included inside of a statement.

 Files cannot be included within a statement.


 159. QP Help: Error: Stack Overflow

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | s_error
 Last Modified: 19-APR-1990    ArticleIdent: Q60794

 The following information is from the QuickPascal Version 1.00
 QPERR.HLP help file:

    Error 162: Stack overflow

 A stack overflow occurred during the link process.


 160. QP Help: Run-Time Error: File Does Not Exist

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | s_error
 Last Modified: 19-APR-1990    ArticleIdent: Q60795

 The following information is from the QuickPascal Version 1.00
 QPERR.HLP help file:

    Run-Time Error 2: File does not exist

 No file exists by the name assigned to the file variable.

 When a file variable that has been assigned the name of a nonexistent
 file is passed to the Append, Erase, Rename, or Reset procedures, this
 error occurs.


 161. QP Help: Run-Time Error: Path Does Not Exist

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | s_error
 Last Modified: 19-APR-1990    ArticleIdent: Q60796

 The following information is from the QuickPascal Version 1.00
 QPERR.HLP help file:

    Run-Time Error 3: Path does not exist

 The specified path name does not exist.

 When a file variable that has been assigned an invalid file name or a
 name of a nonexistent subdirectory is passed to the Append, Erase,
 Rename, Reset, or Rewrite procedures, this error occurs. It also
 occurs when the path passed to ChDir, MkDir, or RmDir is not valid or
 does not exist.


 162. QP Help: Run-Time Error: Out of File Handles

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | s_error
 Last Modified: 19-APR-1990    ArticleIdent: Q60797

 The following information is from the QuickPascal Version 1.00
 QPERR.HLP help file:

    Run-Time Error 4: Out of file handles

 The program ran out of DOS file handles when it tried to open a file.
 This probably occurred during a call to the Append, Reset, or Rewrite
 procedures.

 Increase the setting in CONFIG.SYS to FILES=20, or reduce the number
 of files open at any one time. QuickPascal may use some file handles;
 try to run the program outside the QuickPascal environment.

 TSR (terminate-and-stay-resident) programs may use up file handles.
 Remove resident software, then run the program.


 163. QP Help: Run-Time Error: Invalid File Access

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | s_error
 Last Modified: 19-APR-1990    ArticleIdent: Q60798

 The following information is from the QuickPascal Version 1.00
 QPERR.HLP help file:

    Run-Time Error 5: Invalid file access

 The procedures Append, ChDir, Erase, MkDir, Rename, Reset, Rewrite, or
 RmDir generate this error upon attempting to:

   - Read from a write-only file
   - Write to a read-only file or a directory name
   - Write to or create a file or directory on a full disk
   - Create a directory by an existing name
   - Rename a file to an existing name
   - Rename a directory
   - Remove a read-only file, a nonexistent file, the root directory,
     or a non-empty or nonexistent directory


 164. QP Help: Run-Time Error: Invalid File Handle

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | s_error
 Last Modified: 19-APR-1990    ArticleIdent: Q60799

 The following information is from the QuickPascal Version 1.00
 QPERR.HLP help file:

    Run-Time Error 6: Invalid file handle

 A file handle that was somehow invalid was passed to DOS.

 This may mean that an area of memory was overwritten.


 165. QP Help: Run-Time Error: Invalid Access Code

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | s_error
 Last Modified: 19-APR-1990    ArticleIdent: Q60800

 The following information is from the QuickPascal Version 1.00
 QPERR.HLP help file:

    Run-Time Error 12: Invalid access code

 The Append or Reset procedures found an invalid access code in
 FileMode.


 166. QP Help: Error: Identifier Expected

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | s_error
 Last Modified: 19-APR-1990    ArticleIdent: Q60801

 The following information is from the QuickPascal Version 1.00
 QPERR.HLP help file:

    Error 17: Identifier expected

 The syntax of the current line requires an identifier of some kind.

 An identifer is a name of a constant, type, variable, procedure, or
 function.

 Add an appropriate identifier to the line.


 167. QP Help: Run-Time Error: Invalid Drive Value

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | s_error
 Last Modified: 19-APR-1990    ArticleIdent: Q60802

 The following information is from the QuickPascal Version 1.00
 QPERR.HLP help file:

    Run-Time Error 15: Invalid drive value

 A procedure was passed an invalid value for a drive.

 The ChDir and GetDir procedures give this error if passed an invalid
 drive specification.


 168. QP Help: Run-Time Error: Current Directory May Not Be Deleted

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | s_error
 Last Modified: 19-APR-1990    ArticleIdent: Q60803

 The following information is from the QuickPascal Version 1.00
 QPERR.HLP help file:

    Run-Time Error 16: Current directory may not be deleted

 The RmDir procedure was passed a path that represents the current
 directory.


 169. QP Help: Run-Time Error: Rename Must Occur on Same Drive

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | s_error
 Last Modified: 19-APR-1990    ArticleIdent: Q60804

 The following information is from the QuickPascal Version 1.00
 QPERR.HLP help file:

    Run-Time Error 17: Rename must occur on same drive

 The Rename procedure was passed file names with different drive
 specifications.


 170. QP Help: Run-Time Error: Error in Reading Disk

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | s_error
 Last Modified: 19-APR-1990    ArticleIdent: Q60805

 The following information is from the QuickPascal Version 1.00
 QPERR.HLP help file:

    Run-Time Error 100: Error in reading disk

 The current position was at the end-of-file when an attempt was made
 to read from a file.


 171. QP Help: Run-Time Error: Error in Writing to Disk

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | s_error
 Last Modified: 19-APR-1990    ArticleIdent: Q60806

 The following information is from the QuickPascal Version 1.00
 QPERR.HLP help file:

    Run-Time Error 101: Error in writing to disk

 The disk was full when an attempt was made to write to a file.


 172. QP Help: Run-Time Error: File Not Yet Assigned

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | s_error
 Last Modified: 19-APR-1990    ArticleIdent: Q60809

 The following information is from the QuickPascal Version 1.00
 QPERR.HLP help file:

    Run-Time Error 102: File not yet assigned

 The Append, Erase, Rename, Reset, or Rewrite procedures were passed a
 file variable that had not been assigned to a filename by the Assign
 procedure.


 173. QP Help: Run-Time Error: File Not Open

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | s_error
 Last Modified: 19-APR-1990    ArticleIdent: Q60810

 The following information is from the QuickPascal Version 1.00
 QPERR.HLP help file:

    Run-Time Error 103: File not open

 An I/O operation was attempted on an unopened file.


 174. QP Help: Run-Time Error: File Not Opened for Input

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | s_error
 Last Modified: 19-APR-1990    ArticleIdent: Q60811

 The following information is from the QuickPascal Version 1.00
 QPERR.HLP help file:

    Run-Time Error 104: File not opened for input

 An attempt was made to read from a file that was not opened or was
 opened for output only.


 175. QP Help: Run-Time Error: File Not Opened for Output

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | s_error
 Last Modified: 19-APR-1990    ArticleIdent: Q60812

 The following information is from the QuickPascal Version 1.00
 QPERR.HLP help file:

    Run-Time Error 105: File not opened for output

 An attempt was made to write to a file that was not opened or was
 opened for input only.


 176. QP Help: Run-Time Error: Invalid Numeric Input

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | s_error
 Last Modified: 19-APR-1990    ArticleIdent: Q60813

 The following information is from the QuickPascal Version 1.00
 QPERR.HLP help file:

    Run-Time Error 106: Invalid numeric input

 The numeric format of an input value read by the Read or Readln
 procedures was invalid.


 177. QP Help: Error: ";" Expected

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | s_error
 Last Modified: 19-APR-1990    ArticleIdent: Q60814

 The following information is from the QuickPascal Version 1.00
 QPERR.HLP help file:

    Error 18: ";" expected

 QuickPascal expected a semicolon at or before the current cursor
 location.

 Insert a semicolon at or before the current cursor location, or at
 the end of the previous line.


 178. QP Help: Run-Time Error: Write-Protected Disk

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | s_error
 Last Modified: 19-APR-1990    ArticleIdent: Q60815

 The following information is from the QuickPascal Version 1.00
 QPERR.HLP help file:

    Run-Time Error 150: Write-protected disk

 An attempt was made to write to a write-protected disk.


 179. QP Help: Run-Time Error: Unknown Unit

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | s_error
 Last Modified: 19-APR-1990    ArticleIdent: Q60816

 The following information is from the QuickPascal Version 1.00
 QPERR.HLP help file:

    Run-Time Error 151: Unknown unit

 An I/O operation was directed to a drive or device that does not
 exist.


 180. QP Help: Run-Time Error: Drive or Device Not Ready

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | s_error
 Last Modified: 19-APR-1990    ArticleIdent: Q60817

 The following information is from the QuickPascal Version 1.00
 QPERR.HLP help file:

    Run-Time Error 152: Drive or device not ready

 An I/O operation was directed to a drive that did not contain a floppy
 or whose door was not closed, or to a device that is unable to service
 the request.


 181. QP Help: Run-Time Error: Invalid Command

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | s_error
 Last Modified: 19-APR-1990    ArticleIdent: Q60818

 The following information is from the QuickPascal Version 1.00
 QPERR.HLP help file:

    Run-Time Error 153: Invalid command

 The operating system did not recognize a command that was passed to
 it.


 182. QP Help: Run-Time Error: Data Error (CRC)

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | s_error
 Last Modified: 19-APR-1990    ArticleIdent: Q60819

 The following information is from the QuickPascal Version 1.00
 QPERR.HLP help file:

    Run-Time Error 154: Data error (CRC)

 A disk sector contained a CRC error.


 183. QP Help: Run-Time Error: Length of Request Structure Invalid

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | s_error
 Last Modified: 19-APR-1990    ArticleIdent: Q60820

 The following information is from the QuickPascal Version 1.00
 QPERR.HLP help file:

    Run-Time Error 155: Length of request structure invalid

 An invalid length was used in a disk operation.


 184. QP Help: Run-Time Error: Seek Error

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | s_error
 Last Modified: 19-APR-1990    ArticleIdent: Q60821

 The following information is from the QuickPascal Version 1.00
 QPERR.HLP help file:

    Run-Time Error 156: Seek error

 A DOS error occurred during a seek operation.


 185. QP Help: Run-Time Error: Non-MS-DOS Disk

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | s_error
 Last Modified: 19-APR-1990    ArticleIdent: Q60822

 The following information is from the QuickPascal Version 1.00
 QPERR.HLP help file:

    Run-Time Error 157: Non-MS-DOS disk

 An I/O operation was directed to a disk that is not formatted or is
 formatted for a different system.


 186. QP Help: Run-Time Error: Sector Not Found

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | s_error
 Last Modified: 19-APR-1990    ArticleIdent: Q60823

 The following information is from the QuickPascal Version 1.00
 QPERR.HLP help file:

    Run-Time Error 158: Sector not found

 A nonexistent sector was requested in a disk operation.


 187. QP Help: Run-Time Error: Printer Out of Paper

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | s_error
 Last Modified: 19-APR-1990    ArticleIdent: Q60824

 The following information is from the QuickPascal Version 1.00
 QPERR.HLP help file:

    Run-Time Error 159: Printer out of paper

 An operation was directed to a printer that has no paper.


 188. QP Help: Error: ")" Expected

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | s_error
 Last Modified: 19-APR-1990    ArticleIdent: Q60825

 The following information is from the QuickPascal Version 1.00
 QPERR.HLP help file:

    Error 19: ")" expected

 QuickPascal found an opening parenthesis but cannot find a matching
 closing parenthesis.

 Check for balanced parentheses in lists, enumerated types, arrays,
 record initializations, and in expressions that use parentheses.
 Insert a ")" where you want the list or expression to end.


 189. QP Help: Run-Time Error: Write Fault

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | s_error
 Last Modified: 19-APR-1990    ArticleIdent: Q60826

 The following information is from the QuickPascal Version 1.00
 QPERR.HLP help file:

    Run-Time Error 160: Write fault

 A hardware error occurred.


 190. QP Help: Run-Time Error: Read Fault

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | s_error
 Last Modified: 19-APR-1990    ArticleIdent: Q60827

 The following information is from the QuickPascal Version 1.00
 QPERR.HLP help file:

    Run-Time Error 161: Read fault

 A hardware error occurred.


 191. QP Help: Run-Time Error: General Failure

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | s_error
 Last Modified: 19-APR-1990    ArticleIdent: Q60828

 The following information is from the QuickPascal Version 1.00
 QPERR.HLP help file:

    Run-Time Error 162: General failure

 A hardware or other system error occurred.


 192. QP Help: Run-Time Error: Object Not Allocated

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | s_error
 Last Modified: 19-APR-1990    ArticleIdent: Q60889

 The following information is from the QuickPascal Version 1.00
 QPERR.HLP help file:

    Run-Time Error 180: Object not allocated

 An object was passed to the Dispose procedure without previously
 being allocated by the New procedure.

 This error can also occur if the object structure has been corrupted
 or overwritten.


 193. QP Help: Run-Time Error: Invalid Object Reference

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | s_error
 Last Modified: 19-APR-1990    ArticleIdent: Q60890

 The following information is from the QuickPascal Version 1.00
 QPERR.HLP help file:

    Run-Time Error 181: Invalid object reference

 A method was sent to an object that was not allocated previously by
 the New procedure.

 This error can also occur if the object structure has been corrupted
 or overwritten.


 194. QP Help: Run-Time Error: Division by Zero

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | s_error
 Last Modified: 19-APR-1990    ArticleIdent: Q60891

 The following information is from the QuickPascal Version 1.00
 QPERR.HLP help file:

    Run-Time Error 200: Division by zero

 An attempt was made to divide by zero.


 195. QP Help: Run-Time Error: Range Check Error

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | s_error
 Last Modified: 19-APR-1990    ArticleIdent: Q60892

 The following information is from the QuickPascal Version 1.00
 QPERR.HLP help file:

    Run-Time Error 201: Range check error

 An out-of-range value was assigned to a variable, used as an array
 index, or passed to a procedure or function.

 This error is possible only when range checking is turned on by the
 {$R+} directive.


 196. QP Help: Run-Time Error: Stack Overflow Error

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | s_error
 Last Modified: 19-APR-1990    ArticleIdent: Q60893

 The following information is from the QuickPascal Version 1.00
 QPERR.HLP help file:

    Run-Time Error 202: Stack overflow error

 The stack contained insufficient space for the local variables for a
 procedure or function.

 This error is possible only when stack checking is on. Stack checking
 is turned on by the {$S+} directive.


 197. QP Help: Run-Time Error: Heap Overflow Error

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | s_error
 Last Modified: 19-APR-1990    ArticleIdent: Q60894

 The following information is from the QuickPascal Version 1.00
 QPERR.HLP help file:

    Run-Time Error 203: Heap overflow error

 The heap contained insufficient space for allocation of the specified
 amount of memory by the GetMem or New procedures.


 198. QP Help: Run-Time Error: Invalid Pointer Operation

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | s_error
 Last Modified: 19-APR-1990    ArticleIdent: Q60895

 The following information is from the QuickPascal Version 1.00
 QPERR.HLP help file:

    Run-Time Error 204: Invalid pointer operation

 A pointer set to NIL or to a non-heap location was passed to the
 Dispose or FreeMem procedures.


 199. QP Help: Error: Cannot Open File

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | s_error
 Last Modified: 19-APR-1990    ArticleIdent: Q60896

 The following information is from the QuickPascal Version 1.00
 QPERR.HLP help file:

    Error 2: Cannot open file

 QuickPascal could not open the specified file.

 If the file is a unit, make sure the unit has been compiled into a
 .QPU file.

 If the file is an include file or an .OBJ file, make sure the
 Environment path under the Options menu is correct.


 200. QP Help: Error: "." Expected

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | s_error
 Last Modified: 19-APR-1990    ArticleIdent: Q60897

 The following information is from the QuickPascal Version 1.00
 QPERR.HLP help file:

    Error 20: "." expected

 QuickPascal expected a period after the last END statement in the
 program.

 Insert the period or check the line for correct syntax. Your program
 may be missing a BEGIN statement.


 201. QP Help: Run-Time Error: Floating Point Overflow

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | s_error
 Last Modified: 19-APR-1990    ArticleIdent: Q60898

 The following information is from the QuickPascal Version 1.00
 QPERR.HLP help file:

    Run-Time Error 205: Floating point overflow

 A floating-point operation resulted in an overflow.


 202. QP Help: Run-Time Error: Floating Point Underflow

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | s_error
 Last Modified: 19-APR-1990    ArticleIdent: Q60899

 The following information is from the QuickPascal Version 1.00
 QPERR.HLP help file:

    Run-Time Error 206: Floating point underflow

 A floating-point operation resulted in an underflow.


 203. QP Help: Run-Time Error: Invalid Floating Point Operation

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | s_error
 Last Modified: 19-APR-1990    ArticleIdent: Q60900

 The following information is from the QuickPascal Version 1.00
 QPERR.HLP help file:

    Run-Time Error 207: Invalid floating point operation

 This error occurred because of one of the following:

 - A stack overflow occurred, with either alternate math or
   coprocessor.

 - A non-positive value was passed to the Ln function.

 - A negative value was passed to the Sqrt function.

 - The value passed to the Round or Trunc functions was not in the
 range of a LongInt (-2147483648..2147483647).


 204. QP Help: Error: BEGIN Expected

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | s_error
 Last Modified: 19-APR-1990    ArticleIdent: Q60901

 The following information is from the QuickPascal Version 1.00
 QPERR.HLP help file:

    Error 21: BEGIN expected

 QuickPascal found the start of a statement block without the BEGIN
 keyword.

 If BEGIN is present but in a different location, check for any missing
 keywords such as VAR or DO.


 205. QP Help: Error: END Expected

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | s_error
 Last Modified: 19-APR-1990    ArticleIdent: Q60902

 The following information is from the QuickPascal Version 1.00
 QPERR.HLP help file:

    Error 22: END expected

 QuickPascal found the end of a statement block without the END
 keyword.

 If an END keyword is present, check for balanced BEGIN and END
 statements. Also check for END statements in constructs that expect
 END statements but do not use BEGIN statements (such as CASE
 statements).


 206. QP Help: Error: Label Must Be in the Range 0..9999

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | s_error
 Last Modified: 19-APR-1990    ArticleIdent: Q60903

 The following information is from the QuickPascal Version 1.00
 QPERR.HLP help file:

    Error 23: Label must be in the range 0..9999

 QuickPascal encountered a label that lies outside the accepted range
 of label numbers.

 Change the label to a number between 0 and 9999 or to a unique name.
 If the label is referred to frequently, use the Replace command with
 the Verify option.


 207. QP Help: Error: Identifier or Label Already Defined

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | s_error
 Last Modified: 19-APR-1990    ArticleIdent: Q60904

 The following information is from the QuickPascal Version 1.00
 QPERR.HLP help file:

    Error 25: Identifier or label already defined

 This name is already defined as having a different value or meaning.

 Identifiers within the same scope must be unique. One name can refer
 only to one data type, one procedure, one function, etc. A label can
 be defined only once. A label may not be defined twice in the same
 program.

 Give this identifier a new name, or rename the previous one that uses
 this same name. Change the current label or the previous label with
 the same name or number.


 208. QP Help: Error: Error in Type Definition

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | s_error
 Last Modified: 19-APR-1990    ArticleIdent: Q60905

 The following information is from the QuickPascal Version 1.00
 QPERR.HLP help file:

    Error 26: Error in type definition

 QuickPascal found an error in the definition of this type.

 Check the syntax for what you want to define, and also check any
 limitations of that particular data type.


 209. QP Help: Error: This Type Not Allowed Here

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | s_error
 Last Modified: 19-APR-1990    ArticleIdent: Q60906

 The following information is from the QuickPascal Version 1.00
 QPERR.HLP help file:

    Error 27: This type not allowed here

 The data type of the identifier or value containing the cursor is not
 a valid data type at this location.

 Check the syntax of the code and verify the correct data type. Change
 the identifier or value to the correct type.


 210. QP Help: Error: OF Expected

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | s_error
 Last Modified: 19-APR-1990    ArticleIdent: Q60907

 The following information is from the QuickPascal Version 1.00
 QPERR.HLP help file:

    Error 28: OF expected

 This statement requires an additional OF keyword for completion.

 Check the syntax of the associated statement. For example, CASE
 statements and ARRAY declarations both require the OF keyword as part
 of their complete syntax.


 211. QP Help: Error: Implementation Restriction

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | s_error
 Last Modified: 19-APR-1990    ArticleIdent: Q60908

 The following information is from the QuickPascal Version 1.00
 QPERR.HLP help file:

    Error 29: Implementation restriction

 You exceeded QuickPascal's capacity for this construct.

 Break the construct into smaller pieces.


 212. QP Help: Error: File Too Big

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | s_error
 Last Modified: 25-APR-1990    ArticleIdent: Q61002

 The following information is from the QuickPascal Version 1.00
 QPERR.HLP help file:

    Error 3: File too big

 The file exceeds the maximum size.

 Try putting some procedures and functions into a custom unit and
 compiling again. If the program uses include files, convert them to
 units wherever possible.


 213. QP Help: Error: "]" Expected

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | s_error
 Last Modified: 25-APR-1990    ArticleIdent: Q61003

 The following information is from the QuickPascal Version 1.00
 QPERR.HLP help file:

    Error 31: "]" expected

 QuickPascal found an array or set with unbalanced brackets.

 Balance the brackets by adding the closing square bracket.


 214. QP Help: Error: Unknown Identifier

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | s_error
 Last Modified: 25-APR-1990    ArticleIdent: Q61004

 The following information is from the QuickPascal Version 1.00
 QPERR.HLP help file:

    Error 32: Unknown identifier

 The name at the cursor has not been declared.

 You must declare all names before they can be used. If the name is
 defined in a unit, check that the unit appears in the USES statement.


 215. QP Help: Error: Error in Simple Type Definition

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | s_error
 Last Modified: 25-APR-1990    ArticleIdent: Q61005

 The following information is from the QuickPascal Version 1.00
 QPERR.HLP help file:

    Error 33: Error in simple type definition

 An error was made in defining a simple type.

 Check the syntax of your declaration.


 216. QP Help: Error: Type Identifier Expected

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | s_error
 Last Modified: 25-APR-1990    ArticleIdent: Q61006

 The following information is from the QuickPascal Version 1.00
 QPERR.HLP help file:

    Error 34: Type identifier expected

 QuickPascal expects a data type at the cursor location.

 Add the appropriate data type (for example, Integer, Char, or Double)
 as required by the statement. For instance, array declarations require
 the data type of the array elements, and function declarations require
 both the data types of the returned value and the types of parameters
 passed to the function.


 217. QP Help: Error: "=" Expected

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | s_error
 Last Modified: 25-APR-1990    ArticleIdent: Q61007

 The following information is from the QuickPascal Version 1.00
 QPERR.HLP help file:

    Error 35: "=" expected

 The statement requires an equal sign at the cursor.

 Check the syntax for the statement. This error often occurs in CONST
 initializations or TYPE declarations. Use := for value assignments and
 = for testing equality or initializing a constant.


 218. QP Help: Error: Constant Expected

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | s_error
 Last Modified: 25-APR-1990    ArticleIdent: Q61008

 The following information is from the QuickPascal Version 1.00
 QPERR.HLP help file:

    Error 36: Constant expected

 QuickPascal requires a constant or constant expression at the cursor.

 You cannot use a variable or an expression that uses variables at this
 location.

 Insert a new constant or the appropriate existing constant at the
 cursor.


 219. QP Help: Error: Integer or Real Constant Expected

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | s_error
 Last Modified: 25-APR-1990    ArticleIdent: Q61009

 The following information is from the QuickPascal Version 1.00
 QPERR.HLP help file:

    Error 37: Integer or real constant expected

 QuickPascal requires a numeric constant at the cursor.

 You cannot use a variable or an expression that uses variables at
 this location.

 Insert a new numeric constant or the appropriate existing numeric
 constant at the cursor.


 220. QP Help: Error: Range Expected

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | s_error
 Last Modified: 25-APR-1990    ArticleIdent: Q61010

 The following information is from the QuickPascal Version 1.00
 QPERR.HLP help file:

    Error 38: Range expected

 The syntax used in this statement requires that you specify a range of
 values.

 Specify a range of values with two periods between the lower and upper
 range limits. For example, 1..5 specifies the values 1, 2, 3, 4, and
 5. Examples of keywords that use ranges include CASE and ARRAY.


 221. QP Help: Error: Subrange Bounds Must Be Scalar

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | s_error
 Last Modified: 25-APR-1990    ArticleIdent: Q61011

 The following information is from the QuickPascal Version 1.00
 QPERR.HLP help file:

    Error 39: Subrange bounds must be scalar

 The limiting values of a subrange must be scalar.

 "Scalar" refers to values that are either integers or or enumerated
 data types, such as A..Z. The boundary values cannot be real.

 Replace the subrange bounds with the appropriate scalar values.


 222. QP Help: Error: Incompatible Subrange Types

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | s_error
 Last Modified: 25-APR-1990    ArticleIdent: Q61012

 The following information is from the QuickPascal Version 1.00
 QPERR.HLP help file:

    Error 40: Incompatible subrange types

 The statement contains two different subrange types.

 A subrange type is composed of a specified range of any standard or
 user-defined ordinal types. Subranges consist of elements of the same
 type. The lower and upper bounds of a subrange must be of the same
 data type.

 Change one of the boundary values so that both values share the same
 data type.


 223. QP Help: Error: Too Many Nested Files

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | s_error
 Last Modified: 25-APR-1990    ArticleIdent: Q61013

 The following information is from the QuickPascal Version 1.00
 QPERR.HLP help file:

    Error 4: Too many nested files

 The program nests include files too deeply. If the files included must
 include other files, keep the nesting to a maximum depth of eight
 files.

 Convert some of the include files to units.


 224. QP Help: Error: Low Bound Exceeds High Bound

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | s_error
 Last Modified: 25-APR-1990    ArticleIdent: Q61014

 The following information is from the QuickPascal Version 1.00
 QPERR.HLP help file:

    Error 41: Low bound exceeds high bound

 The low bound range in a declared array exceeds the high bound range.
 For example:

    ARRAY[1..10] OF Integer;    {correct}
    TYPE
        my_rg = 1..10;

    ARRAY[10..1] OF Integer;    {incorrect}
    TYPE
        my_rg = 10..1;


 225. QP Help: Error: ":" Expected

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | s_error
 Last Modified: 25-APR-1990    ArticleIdent: Q61015

 The following information is from the QuickPascal Version 1.00
 QPERR.HLP help file:

    Error 42: ":" expected

 A colon (:) was expected but did not occur in the statement. The ":"
 symbol is used to

 - Declare a variable

 - Designate a label within a program

 - Identify a constant in a CASE statement

 - Indicate a value will be returned by a function


 226. QP Help: Error: Unsatisfied Forward Reference

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | s_error
 Last Modified: 25-APR-1990    ArticleIdent: Q61016

 The following information is from the QuickPascal Version 1.00
 QPERR.HLP help file:

    Error 43: Unsatisfied forward reference

 The formal parameter list and block has not been declared for a
 FORWARD procedure.


 227. QP Help: Error: Integer Constant Expected

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | s_error
 Last Modified: 25-APR-1990    ArticleIdent: Q61017

 The following information is from the QuickPascal Version 1.00
 QPERR.HLP help file:

    Error 44: Integer constant expected

 An integer constant was expected in the statement. Replace the
 variable identifier with an integer constant.


 228. QP Help: Error: Invalid String Length

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | s_error
 Last Modified: 25-APR-1990    ArticleIdent: Q61018

 The following information is from the QuickPascal Version 1.00
 QPERR.HLP help file:

    Error 45: Invalid string length

 The length of a string must be an integer between 1 and 255.


 229. QP Help: Error: Tag Field Type Must Be Scalar or Subrange

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | s_error
 Last Modified: 24-APR-1990    ArticleIdent: Q61019

 The following information is from the QuickPascal Version 1.00
 QPERR.HLP help file:

    Error 46: Tag field type must be scalar or subrange

 The tag field in the variant record must be either a scalar or
 subrange type.

 Tag fields are separate fields of a record that indicate the variant
 used in the record variable.


 230. QP Help: Error: "(" Expected

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | s_error
 Last Modified: 25-APR-1990    ArticleIdent: Q61020

 The following information is from the QuickPascal Version 1.00
 QPERR.HLP help file:

    Error 47: "(" expected

 A left parenthesis "(" must be paired with a right parenthesis ")".
 Check statements with nested parentheses to verify that the number of
 right and left parentheses match.


 231. QP Help: Error: Too Many Literals

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | s_error
 Last Modified: 24-APR-1990    ArticleIdent: Q61021

 The following information is from the QuickPascal Version 1.00
 QPERR.HLP help file:

    Error 48: Too many literals

 The program has too many literal constants to fit into memory. Reduce
 the number of constants by passing parameters to procedures and
 functions.


 232. QP Help: Error: Error in Expression

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | s_error
 Last Modified: 25-MAY-1990    ArticleIdent: Q61114

 The following information is from the QuickPascal Version 1.00
 QPERR.HLP help file:

    Error 50: Error in expression

 An undefined syntax error occurred in the expression.


 233. QP Help: Error: Cannot Read File

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | s_error
 Last Modified: 25-MAY-1990    ArticleIdent: Q61115

 The following information is from the QuickPascal Version 1.00
 QPERR.HLP help file:

    Error 5: Cannot read file

 QuickPascal cannot read from the specified file.

 Check that the disk drive functions properly and that the disk
 contains no errors or bad sectors.


 234. QP Help: Error: Conflicting Operands

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | s_error
 Last Modified: 25-MAY-1990    ArticleIdent: Q61116

 The following information is from the QuickPascal Version 1.00
 QPERR.HLP help file:

    Error 51: Conflicting operands

 The operands in the expression are of an incompatible type. For
 example,

    'A' DIV 5


 235. QP Help: Error: Right Operand Is Not a Set

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | s_error
 Last Modified: 25-MAY-1990    ArticleIdent: Q61117

 The following information is from the QuickPascal Version 1.00
 QPERR.HLP help file:

    Error 52: Right operand is not a set

 The operand to the right of a set operator is not a set. Set
 operations can only be performed on sets.


 236. QP Help: Error: Invalid Identifier

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | s_error
 Last Modified: 25-MAY-1990    ArticleIdent: Q61118

 The following information is from the QuickPascal Version 1.00
 QPERR.HLP help file:

    Error 53: Invalid identifier

 An identifier was used in an illegal context.


 237. QP Help: Error: Invalid Type Cast

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | s_error
 Last Modified: 25-MAY-1990    ArticleIdent: Q61119

 The following information is from the QuickPascal Version 1.00
 QPERR.HLP help file:

    Error 54: Invalid type cast

 An attempt has been made to cast to an incompatible type. Check to
 see if the type is compatible.


 238. QP Help: Error: Cannot Create File

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | s_error
 Last Modified: 25-MAY-1990    ArticleIdent: Q61120

 The following information is from the QuickPascal Version 1.00
 QPERR.HLP help file:

    Error 55: Cannot create file

 An I/O error has prevented the file from being created.

 Check for defective disk media.


 239. QP Help: Error: Cannot Write File

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | s_error
 Last Modified: 25-MAY-1990    ArticleIdent: Q61121

 The following information is from the QuickPascal Version 1.00
 QPERR.HLP help file:

    Error 56: Cannot write file

 An I/O error has prevented the file from being written.

 Check for defective disk media.


 240. QP Help: Error: Variable Type Must Be Pointer

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | s_error
 Last Modified: 25-MAY-1990    ArticleIdent: Q61122

 The following information is from the QuickPascal Version 1.00
 QPERR.HLP help file:

    Error 57: Variable type must be pointer

 The variable in this statement must be of a pointer type.

 You may be trying to dereference something that is not a pointer.


 241. QP Help: Error: Variable Type Must Be Record

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | s_error
 Last Modified: 25-MAY-1990    ArticleIdent: Q61123

 The following information is from the QuickPascal Version 1.00
 QPERR.HLP help file:

    Error 58: Variable type must be record

 The variable in the statement must be of a record type.


 242. QP Help: Error: Variable Type Must Be Array or String

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | s_error
 Last Modified: 25-MAY-1990    ArticleIdent: Q61124

 The following information is from the QuickPascal Version 1.00
 QPERR.HLP help file:

    Error 59: Variable type must be array or string

 The variable in the statement must be declared as an array or a
 string.


 243. QP Help: Error: No Such Field in This Record or Object

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | s_error
 Last Modified: 25-MAY-1990    ArticleIdent: Q61125

 The following information is from the QuickPascal Version 1.00
 QPERR.HLP help file:

    Error 60: No such field in this record or object

 A field does not exist in this record or object type with the
 specified identifier.

 Check the declaration to verify that the field exists.


 244. QP Help: Error: Cannot Close File

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | s_error
 Last Modified: 25-MAY-1990    ArticleIdent: Q61126

 The following information is from the QuickPascal Version 1.00
 QPERR.HLP help file:

    Error 6: Cannot close file

 QuickPascal cannot close the specified file.

 Check that the disk drive functions properly and that the disk
 contains no errors or bad sectors.


 245. QP Help: Error: Index Type Is Not Compatible with Declaration

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | s_error
 Last Modified: 25-MAY-1990    ArticleIdent: Q61127

 The following information is from the QuickPascal Version 1.00
 QPERR.HLP help file:

    Error 61: Index type is not compatible with the
            declaration

 The specified index type, or subscript, of the array in this
 statement is not consistent with the original array declaration. For
 example, given the declarations:

    VAR
        TheGrade   : Array[ 1..25 ] OF Char;
        the_letter : Char;

 the error occurs on the following line:

    the_letter := TheGrade[ 'A' ];


 246. QP Help: Error: Routine Too Big

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | s_error
 Last Modified: 25-MAY-1990    ArticleIdent: Q61128

 The following information is from the QuickPascal Version 1.00
 QPERR.HLP help file:

    Error 62: Routine too big

 The procedure or function is too large to fit into memory.

 Divide the routine into smaller components.


 247. QP Help: Error: UNTIL Expected

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | s_error
 Last Modified: 25-MAY-1990    ArticleIdent: Q61129

 The following information is from the QuickPascal Version 1.00
 QPERR.HLP help file:

    Error 63: UNTIL expected

 UNTIL was expected in the statement but not found.

 A REPEAT statement must include an UNTIL keyword, as in

    REPEAT
        TestCase;
    UNTIL the_var = 1;


 248. QP Help: Error: Boolean Expression Expected

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | s_error
 Last Modified: 25-MAY-1990    ArticleIdent: Q61130

 The following information is from the QuickPascal Version 1.00
 QPERR.HLP help file:

    Error 64: Boolean expression expected

 The expression being evaluated in a conditional statement must
 produce a result of type Boolean.


 249. QP Help: Error: DO Expected

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | s_error
 Last Modified: 25-MAY-1990    ArticleIdent: Q61131

 The following information is from the QuickPascal Version 1.00
 QPERR.HLP help file:

    Error 65: DO expected

 DO was expected in the statement but not found.

 A WHILE statement or a WITH statement must include a DO keyword, as
 in

    WHILE (Eof( myfile ) = False) DO
        Readln( myfile );
 or

    WITH the_record DO
        the_size := 10;


 250. QP Help: Error: THEN Expected

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | s_error
 Last Modified: 25-MAY-1990    ArticleIdent: Q61132

 The following information is from the QuickPascal Version 1.00
 QPERR.HLP help file:

    Error 66: THEN expected

 THEN was expected in the statement but not found.

 An IF statement must include a THEN keyword, as in

    IF (the_color = red) THEN
        DisplayStopSign;


 251. QP Help: Error: Invalid Label

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | s_error
 Last Modified: 25-MAY-1990    ArticleIdent: Q61133

 The following information is from the QuickPascal Version 1.00
 QPERR.HLP help file:

    Error 67: Invalid label

 The label is incorrectly defined.

 A label is a digit sequence whose value ranges from 0 to 9999.
 Leading zeros are not significant.


 252. QP Help: Error: Unknown Label

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | s_error
 Last Modified: 25-MAY-1990    ArticleIdent: Q61134

 The following information is from the QuickPascal Version 1.00
 QPERR.HLP help file:

    Error 68: Unknown label

 The label referred to by the GOTO statement could not be located.

 A label must occur within the scope of the current block.


 253. QP Help: Error: Label Not Within Current Block

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | s_error
 Last Modified: 25-MAY-1990    ArticleIdent: Q61135

 The following information is from the QuickPascal Version 1.00
 QPERR.HLP help file:

    Error 69: Label not within current block

 A GOTO statement cannot refer to a label outside the current block.
 Either place the label within the scope of the block, or use a
 procedure or function.


 254. QP Help: Error: Label Already Defined

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | s_error
 Last Modified: 25-MAY-1990    ArticleIdent: Q61136

 The following information is from the QuickPascal Version 1.00
 QPERR.HLP help file:

    Error 70: Label already defined

 A label with the same name has already been defined.

 Rename the label with a unique name.


 255. QP Help: Error: Cannot Seek File

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | s_error
 Last Modified: 25-MAY-1990    ArticleIdent: Q61137

 The following information is from the QuickPascal Version 1.00
 QPERR.HLP help file:

    Error 7: Cannot seek file

 The compiler could not seek the specified file.

 This is typically a hardware problem. Check that the disk drive is
 functioning properly.


 256. QP Help: Error: Label Expected

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | s_error
 Last Modified: 25-MAY-1990    ArticleIdent: Q61138

 The following information is from the QuickPascal Version 1.00
 QPERR.HLP help file:

    Error 71: Label expected

 The GOTO statement must include a label. For example,

    GOTO 1000;


 257. QP Help: Error: Undefined Label in Preceding Statement Part

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | s_error
 Last Modified: 25-MAY-1990    ArticleIdent: Q61139

 The following information is from the QuickPascal Version 1.00
 QPERR.HLP help file:

    Error 72: Undefined label in preceding statement part

 The label referenced by the GOTO statement has not been defined. A
 label must occur within the scope of the current block.


 258. QP Help: Error: Error in Statement

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | s_error
 Last Modified: 25-MAY-1990    ArticleIdent: Q61140

 The following information is from the QuickPascal Version 1.00
 QPERR.HLP help file:

    Error 73: Error in statement

 An undefined error has occurred in the statement.


 259. QP Help: Error: ":=" Expected

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | s_error
 Last Modified: 25-MAY-1990    ArticleIdent: Q61141

 The following information is from the QuickPascal Version 1.00
 QPERR.HLP help file:

    Error 74: ":=" expected

 A ":=" was expected but did not occur in the statement.

 The assignment operator (:=) assigns a value to a variable or
 function. Do not confuse ":=" with the equivalence operator (=).


 260. QP Help: Error: Type Mismatch

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | s_error
 Last Modified: 25-MAY-1990    ArticleIdent: Q61142

 The following information is from the QuickPascal Version 1.00
 QPERR.HLP help file:

    Error 75: Type mismatch

 A type-incompatibility situation occurred, for one of the following
 reasons:

 - The variable and the expression in an assignment statement were not
   compatible types.

 - An actual parameter passed to a procedure or function was not
   type-compatible with a formal parameter.

 - An expression contained incompatible types of operands.

 - An expression used as an array index was not type-compatible for
   indexing an array.


 261. QP Help: Error: Variable Identifier Expected

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | s_error
 Last Modified: 25-MAY-1990    ArticleIdent: Q61143

 The following information is from the QuickPascal Version 1.00
 QPERR.HLP help file:

    Error 76: Variable identifier expected

 A variable was expected in the statement.

 Replace the constant with a variable identifier.


 262. QP Help: Error: Invalid FOR Control Variable

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | s_error
 Last Modified: 25-MAY-1990    ArticleIdent: Q61144

 The following information is from the QuickPascal Version 1.00
 QPERR.HLP help file:

    Error 77: Invalid FOR control variable

 The control variable in a FOR statement must be of an ordinal type.


 263. QP Help: Error: Scalar Type Expected

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | s_error
 Last Modified: 25-MAY-1990    ArticleIdent: Q61145

 The following information is from the QuickPascal Version 1.00
 QPERR.HLP help file:

    Error 78: Scalar type expected

 A scalar type was expected in the statement.

 A scalar type has a finite number of elements. Scalar types include
 Boolean, Char, enumerated types, integer types, and subranges.


 264. QP Help: Error: TO or DOWNTO Expected

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | s_error
 Last Modified: 25-MAY-1990    ArticleIdent: Q61146

 The following information is from the QuickPascal Version 1.00
 QPERR.HLP help file:

    Error 79: TO or DOWNTO expected

 The keywords TO or DOWNTO are required in a FOR statement. For
 example,

    FOR loop := 1 TO 10
 or
    FOR loop := 100 DOWNTO 10


 265. QP Help: Error: Disk Full

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | s_error
 Last Modified: 25-MAY-1990    ArticleIdent: Q61147

 The following information is from the QuickPascal Version 1.00
 QPERR.HLP help file:

    Error 80: Disk full

 The disk is too full to continue the operation. Exit to DOS and
 delete unwanted files to free additional space.


 266. QP Help: Error: Invalid End of Line

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | s_error
 Last Modified: 25-MAY-1990    ArticleIdent: Q61148

 The following information is from the QuickPascal Version 1.00
 QPERR.HLP help file:

    Error 8: Invalid end of line

 QuickPascal encountered a carriage return without a line feed or a
 line feed without a preceding carriage return.

 Re-enter the end-of-line character to correct the line terminator.


 267. QP Help: Error: Constant Value Out of Range

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | s_error
 Last Modified: 25-MAY-1990    ArticleIdent: Q61149

 The following information is from the QuickPascal Version 1.00
 QPERR.HLP help file:

    Error 81: Constant value out of range

 A value exceeded the acceptable range for the data type of the
 constant.

 QuickPascal infers the acceptable range of a constant based on the
 type of value entered.

 Reassign the constant a value within the range of the current data
 type, or change the data type.


 268. QP Help: Error: "," Expected

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | s_error
 Last Modified: 25-MAY-1990    ArticleIdent: Q61150

 The following information is from the QuickPascal Version 1.00
 QPERR.HLP help file:

    Error 82: "," expected

 QuickPascal expects a comma between items in a list, such as multiple
 parameters passed to a procedure or function.

 Insert a comma at the current cursor location.


 269. QP Help: Error: Division by Zero

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | s_error
 Last Modified: 25-MAY-1990    ArticleIdent: Q61151

 The following information is from the QuickPascal Version 1.00
 QPERR.HLP help file:

    Error 83: Division by zero

 The divisor in the expression evaluated to zero, resulting in a
 division by zero.

 Alter the value of the divisor.


 270. QP Help: Error: Too Many Local Routines

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | s_error
 Last Modified: 25-MAY-1990    ArticleIdent: Q61152

 The following information is from the QuickPascal Version 1.00
 QPERR.HLP help file:

    Error 84: Too many local routines

 The maximum number of procedures and functions that QuickPascal can
 handle locally has been exceeded.

 Move some of the procedures or functions to a global level, or create
 a unit for some of the routines.


 271. QP Help: Error: Integer Expression Expected

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | s_error
 Last Modified: 25-MAY-1990    ArticleIdent: Q61153

 The following information is from the QuickPascal Version 1.00
 QPERR.HLP help file:

    Error 85: Integer expression expected

 The expression was not an integer type.

 Change the result of the expression to an integer type. If you need
 to convert a real number to an integer, use the Trunc function.


 272. QP Help: Error: Pointer Type Cannot Be Referenced

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | s_error
 Last Modified: 25-MAY-1990    ArticleIdent: Q61154

 The following information is from the QuickPascal Version 1.00
 QPERR.HLP help file:

    Error 86: Pointer type cannot be referenced

 The pointer type cannot be referenced.

 Cast or assign the pointer to a typed pointer.


 273. QP Help: Error: Typed Pointer Expected

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | s_error
 Last Modified: 25-MAY-1990    ArticleIdent: Q61155

 The following information is from the QuickPascal Version 1.00
 QPERR.HLP help file:

    Error 87: Typed pointer expected

 The statement expects a typed pointer.

 Replace the untyped pointer variable at the cursor with a typed
 pointer variable.


 274. QP Help: Error: File Type Expected

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | s_error
 Last Modified: 25-MAY-1990    ArticleIdent: Q61156

 The following information is from the QuickPascal Version 1.00
 QPERR.HLP help file:

    Error 88: File type expected

 A typed, untyped, or text file was expected.


 275. QP Help: Error: Cannot Write Expressions of This Type

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | s_error
 Last Modified: 25-MAY-1990    ArticleIdent: Q61157

 The following information is from the QuickPascal Version 1.00
 QPERR.HLP help file:

    Error 89: Cannot write expressions of this type

 The Write and Writeln statements can print only numeric, string, and
 Boolean data. A command to print a complex or user-defined data type
 such as a record, set, pointer, or enumeration has been entered; this
 cannot be done.

 Convert the value to a string and then print the string.


 276. QP Help: Error: Ordinal Expression Expected

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | s_error
 Last Modified: 25-MAY-1990    ArticleIdent: Q61158

 The following information is from the QuickPascal Version 1.00
 QPERR.HLP help file:

    Error 90: Ordinal expression expected

 A procedure or function expected an ordinal type.

 A variable passed to this procedure or function must be of an ordinal
 type. An expression passed to it must evaluate to an ordinal value.


 277. QP Help: Error: Illegal Character

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | s_error
 Last Modified: 25-MAY-1990    ArticleIdent: Q61159

 The following information is from the QuickPascal Version 1.00
 QPERR.HLP help file:

    Error 9: Illegal character

 QuickPascal encountered an invalid character.

 Some illegal characters do not appear on the screen. QuickPascal
 placed the cursor where it found the invalid character. Use the DEL
 key to remove that character (and retype it if necessary). If the
 problem persists, retype the entire line.

 Valid QuickPascal source code characters are a..z, A..Z, 0..9, $ @ _
 ; : , . + - * / = ^ ' # < > [ ] ( ) { } and " " (blank space). Other
 characters are valid only in comments.


 278. QP Help: Error: Invalid File Type

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | s_error
 Last Modified: 25-MAY-1990    ArticleIdent: Q61160

 The following information is from the QuickPascal Version 1.00
 QPERR.HLP help file:

    Error 91: Invalid file type

 The file operation does not accept a file of this type.

 Check the syntax for the file operation and make sure the operation
 accepts the file type you specified. This problem often occurs if you
 try to use a Text file operation on a binary file or vice versa.


 279. QP Help: Error: Variable Parameter Expected

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | s_error
 Last Modified: 25-MAY-1990    ArticleIdent: Q61161

 The following information is from the QuickPascal Version 1.00
 QPERR.HLP help file:

    Error 92: Variable parameter expected

 A constant or expression has been specified where Pascal requires a
 variable.

 Replace the parameter with a variable reference.


 280. QP Help: Error: Cannot Read Expressions of This Type

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | s_error
 Last Modified: 25-MAY-1990    ArticleIdent: Q61162

 The following information is from the QuickPascal Version 1.00
 QPERR.HLP help file:

    Error 93: Cannot read expressions of this type

 The Read and Readln statements accept only numeric, string, and
 Boolean data. If you wish to read in a user-defined type, such as a
 set or pointer, read the value as a number and then convert it to the
 appropriate value.


 281. QP Help: Error: Integer or Real Expression Expected

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | s_error
 Last Modified: 25-MAY-1990    ArticleIdent: Q61163

 The following information is from the QuickPascal Version 1.00
 QPERR.HLP help file:

    Error 94: Integer or real expression expected

 QuickPascal expects an expression that evaluates to an integer or
 real value. Modify the expression as needed so that it results in
 either an integer or real number.


 282. QP Help: Error: Integer or Real Variable Expected

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | s_error
 Last Modified: 25-MAY-1990    ArticleIdent: Q61164

 The following information is from the QuickPascal Version 1.00
 QPERR.HLP help file:

    Error 95: Integer or real variable expected

 QuickPascal expects a numeric variable of an integer or real type at
 the cursor location.


 283. QP Help: Error: INLINE Error

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | s_error
 Last Modified: 25-MAY-1990    ArticleIdent: Q61165

 The following information is from the QuickPascal Version 1.00
 QPERR.HLP help file:

    Error 97: INLINE error

 There is an error in the INLINE statement syntax. Check the
 machine-language and INLINE syntax carefully.


 284. QP Help: Error: Label Definition Not Allowed in INTERFACE

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | s_error
 Last Modified: 25-MAY-1990    ArticleIdent: Q61166

 The following information is from the QuickPascal Version 1.00
 QPERR.HLP help file:

    Error 98: Label definition not allowed in INTERFACE part

 Labels cannot be defined in the INTERFACE portion of a unit. Define
 any labels in the IMPLEMENTATION section of the unit.


 285. QP Help: Error: INTERFACE Expected

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | s_error
 Last Modified: 25-MAY-1990    ArticleIdent: Q61167

 The following information is from the QuickPascal Version 1.00
 QPERR.HLP help file:

    Error 99: INTERFACE expected

 QuickPascal expects an INTERFACE statement immediately following the
 unit declaration. Any variables, constants, procedures, etc., that
 you want a calling program to have access to must appear within the
 INTERFACE portion of the unit. Place any declarations that you do not
 want the calling program to access in the IMPLEMENTATION section of
 the unit.


 286. QP Help: Error: IMPLEMENTATION Expected

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | s_error
 Last Modified: 25-MAY-1990    ArticleIdent: Q61168

 The following information is from the QuickPascal Version 1.00
 QPERR.HLP help file:

    Error 100: IMPLEMENTATION expected

 Place an IMPLEMENTATION statement prior to any executable code. If
 there are declarations that you do not want the calling program to
 have access to, place them in the IMPLEMENTATION section of a unit.
 Such declarations typically include variables, constants, etc., that
 need to be available to all of the unit's procedure and function
 definitions.


 287. QP Help: Error: Invalid Unit File

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | s_error
 Last Modified: 25-MAY-1990    ArticleIdent: Q61169

 The following information is from the QuickPascal Version 1.00
 QPERR.HLP help file:

    Error 101: Invalid unit file

 The USES statement refers to a file that is not a valid unit.

 Check the spelling of the name you referenced. Make sure the program
 or file is compatible with QuickPascal.


 288. _GFillInterior Does Not Always Fill Ellipse

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | s_quickc
 Last Modified: 25-MAY-1990    ArticleIdent: Q61311

 The following code demonstrates that the _GFillInterior flag will not
 fill the ellipse if the center of that ellipse is off the screen:

 PROGRAM Show;

 USES MSGraph, Crt;

 VAR
    DummyInt:Integer;
    DummyChar:Char;

 BEGIN
    DummyInt := _SetVideoMode(_EResColor);
    (** This one fills ok **)
    _Ellipse(_GFillInterior,220,75,420,275);

    (** This one does not **)
    _Ellipse(_GFillInterior,220,280,420,480);

    DummyChar := ReadKey;
    DummyInt := _SetVideoMode(_DefaultMode);
 END.

 _GFILLINTERIOR works differently depending on whether it is used with
 one class of function (_rectangle and _polygon) or the other (_ellipse
 and _pie). In the first case (for example, _rectangle and _polygon), a
 polygon scanfill is done that fills based on the shape of the object,
 regardless of where it is on the screen, or any other objects (or
 lines) within the object. This is usually the best approach, since it
 fills the way you would normally expect.

 The second case (for example, _ellipse) is handled differently. In
 this case, it is equivalent to doing a _floodfill() call, using the
 current color as the border, with the starting position at the
 "center" of the ellipse. _pie is equally arbitrary, although it uses a
 point about 3/4 of the way along a line bisecting the arc. The key in
 either case is that the starting-point is arbitrary and fixed. If that
 point is outside the viewport or is already drawn in the
 border/drawing color, the floodfill doesn't do anything.

 Also, because it is a floodfill, not a scanfill, objects or lines
 inside the ellipse/pie can cause it to not be filled entirely, whereas
 scanfill always fills completely. This is by design.

 One reason for adding _polygon to C Version 6.00 is to add the ability
 to draw virtually any shape (for example: you can simulate ellipses
 and pies) and still do a scanfill.


 289. QuickPascal May Not Correctly Reset Colors When Exiting

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 11-SEP-1990    ArticleIdent: Q65500

 Under certain circumstances, Microsoft QuickPascal (QP) version 1.00
 does not correctly reset all colors when exiting back to DOS.
 QuickPascal seems to change the color palette when it was previously
 set by DOS. The problem has been reproduced only on machines that use
 Compaq VGA cards.

 By design, QuickPascal does not make any assumptions about your
 intentions when modifying colors. If you are within the environment
 and modified any colors, QP will not reset these colors when you exit.
 The following procedure demonstrates this behavior:

 1. Compile the following program under QuickPascal version 1.00 and
    then exit to DOS.

       program colortst;
       uses crt;
       var
          i : integer;
       begin
          for i:=1 to 15 do begin
             textcolor(i);
             writeln('this is color ',i);
          end;
       end.

 2. At the DOS prompt, type "MODE CO80".

 3. Run "colortst". This will display 15 lines of text in different
    colors.

 4. Enter QuickPascal and then exit.

 Color #6 of the program will change from light brown to light yellow.

 As a workaround, the following batch file can be used to set the
 colors back to the default:

    mode co80
    qp %1 %2 %3 %4 %5
    mode co80


 290. Use RESET(fh,recordsize) When Working with Non-Typed Files

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist1.00 SR# S900910-39
 Last Modified: 26-DEC-1990    ArticleIdent: Q65570

 Microsoft QuickPascal contains a variable type of "FILE" that declares
 a file handle for an un-typed file. This is useful in conjunction with
 the BlockRead and BlockWrite statements in that it allows you to open
 any file and then READ or WRITE any type of data to the file. (This is
 equivalent to OPENing a file for BINARY and using the GET and PUT file
 I/O statements in BASIC.)

 To prevent unexpected errors of "Runtime error - 100" (which is
 attempting to read past the end of file), the RESET statement's
 optional second parameter must be used. This second parameter
 specifies the logical record length for the file. If not specified,
 the record size defaults to 128 bytes.

 This information applies to Microsoft QuickPascal version 1.00 for
 MS-DOS.

 Since the default for the record size parameter of the RESET statement
 is 128-bytes in length, failing to use this parameter when working
 with non-type files will usually result in "Runtime error - 100,"
 attempt to read past end of file. This is because all files are not a
 multiple of 128-bytes in length.

 The following sample program demonstrates how not using the record
 size parameter of the RESET statement can lead to "Runtime error -
 100."

 To run the programs below, you must create a file called TEST.DAT.
 Contents of TEST.DAT should be as follows:

    ABCDEFGHIJKLMNOPQRSTUVWXYZ

 Sample Program 1
 ----------------

 PROGRAM ResetTest;
 VAR fh: FILE;
      s: STRING[26];
 BEGIN
   ASSIGN(fh, 'test.dat');
   RESET(fh);              { Opens file with record size of 128-bytes.}
   BlockRead(fh, s, 1);    { Attempts to READ one 128-byte record but}
   WRITELN(s);             { fails because the file is only 26 bytes.}
   CLOSE(fh);
 END.

 When the above program is executed, the BlockRead statement will
 generate "Runtime error - 100" because the default record size is
 128-bytes and the file is only 26-bytes in length. Changing the RESET
 statement to include a record size parameter from 1 to 26 will allow
 the program to execute successfully. The following program will
 execute without error:

 Sample Program 2
 ----------------

 PROGRAM ResetTest;
 VAR fh: FILE;
      s: STRING[26];
 BEGIN
   ASSIGN(fh, 'test.dat');
   RESET(fh, 26);          { Opens file with record size of 26-bytes.}
   BlockRead(fh, s, 1);    { Reads one 26-bytes record.              }
   WRITELN(s);
   CLOSE(fh);
 END.


 291. Excellent "QuickPascal Programming" Book from MS Press

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | s_pascal manual
 Last Modified: 24-OCT-1990    ArticleIdent: Q65878

 The following excellent book is available to support customers of
 Microsoft QuickPascal version 1.00:

    "Microsoft QuickPascal Programming", by Kris Jamsa, published
    by Microsoft Press, copyright 1990.

 This book teaches both the Pascal language and the Microsoft
 QuickPascal environment, and is an excellent guide for beginning,
 intermediate, and advanced Pascal programmers. This book is a great
 supplement to the existing documentation and online help shipped with
 Microsoft QuickPascal 1.00.


 292. Comparison of Pascal 4.00 and QuickPascal: Which Should I Buy?

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | SR# S900927-116 S_Pascal
 Last Modified:  8-OCT-1990    ArticleIdent: Q66011

 This article compares Microsoft Pascal version 4.00 with Microsoft
 QuickPascal version 1.00. This information may be very important when
 deciding which product to buy or use.

 The only advantages to using Microsoft Pascal 4.00 are the ability to
 create OS/2 programs and to perform interlanguage calling. Otherwise,
 the Pascal 4.00 package is substantially more difficult to use than
 QuickPascal 1.00.

 QuickPascal offers a powerful and easy-to-use programming environment.

 This information applies to Microsoft QuickPascal version 1.00 for
 MS-DOS and to Microsoft Pascal Compiler version 4.00 for MS-DOS and MS
 OS/2.

 COMPARISON OF PASCAL 4.00 COMPILER WITH QUICKPASCAL 1.00
 --------------------------------------------------------

 Which Operating Systems Are Supported
 -------------------------------------

 QuickPascal 1.00 can only run under DOS or in the DOS compatibility
 box of Windows or OS/2. Programs compiled with QuickPascal can only
 run under DOS.

 Pascal 4.00 can create programs for either DOS or OS/2. Pascal 4.00
 also comes with libraries that enable you to create programs for
 Microsoft Windows versions 2.x for MS-DOS, but NOT for Windows version
 3.00.

 Programming Environment of QuickPascal Versus Pascal
 ----------------------------------------------------

 QuickPascal comes with an integrated programming environment, QP.EXE.
 Like the other Microsoft "Quick" products, QP.EXE has a
 character-oriented window interface. This means that you write
 programs in a window or series of windows. (Internally, the windows in
 QP.EXE are not stored as bit-mapped graphical windows, but are instead
 created in text mode with graphics characters and text.) QP.EXE has
 overlapping windows. Common editor functions can be accessed from
 pull-down menus accessible by the ALT key or by a mouse click. QP.EXE
 has the following menus:

    Menu Name   Purpose
    ---------   -------

    File        Managing multiple files
    Debug       Debugging programs
    Search      Search and replace
    Make        Program building and program management
    Options     Customizing the editor and programming environment
    View        Managing programming windows and the output screen
    Help        Access to online help

 The QuickPascal QP.EXE environment has a complete online help system
 and context-sensitive help similar to the other Microsoft Quick
 products. QP.EXE has full mouse support.

 Pascal 4.00 does not come with a programming environment, but instead
 comes with the Microsoft Editor (M.EXE or MEP.EXE). The Microsoft
 Editor is a programmer's editor with most of the standard editing
 functions, such as cutting and pasting text, searching and replacing,
 and managing multiple files. The Pascal compiler can be launched from
 within the Microsoft Editor. This editor can be customized by writing
 extensions in C and compiling them. The Microsoft Editor is difficult
 to learn and use, but it is a powerful editor with many useful
 features. The Pascal 4.00 compiler will compile any programs that are
 ASCII text files, thus programmers can use any editor of their choice,
 as long as they save the Pascal source code as text.

 Interlanguage Calling
 ---------------------

 Programs compiled in QuickPascal can only call programs created in
 assembly language.

 Programs compiled in Pascal 4.00 can call programs created with the
 Microsoft family of languages, including C, FORTRAN, BASIC, COBOL, or
 assembly language. (Note that only certain versions of C, FORTRAN,
 BASIC, and COBOL can link with Pascal 4.00.)

 Compatibility / Portability
 ---------------------------

 QuickPascal 1.00 is highly source-code compatible with Borland's Turbo
 Pascal 5.00. Porting code to and from Turbo Pascal 5.00 is a fairly
 straightforward process.

 Pascal 4.00 is very minimally source-code compatible with Borland's
 Turbo Pascal products. Porting code to or from Turbo Pascal requires
 extensive source code changes.


 293. No Color on Magnavox VGA Using QP or QC GRAPHICS.LIB

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | SR# S901005-21 S_C S_QuickC
 Last Modified: 26-DEC-1990    ArticleIdent: Q66423

 Customers have reported that the GRDEMO program shipped with both
 QuickPascal version 1.00 and QuickC version 2.00 does not run in color
 on a Magnavox VGA Adapter. The resolution is correct but the colors
 are shades of gray.

 The problem was reported with Magnavox VGA BIOS version 1.05.
 Customers have reported that this problem is resolved in Magnavox VGA
 BIOS version 1.11.

 This information applies to QuickPascal version 1.00, to QuickC
 versions 2.00, 2.01, 2.50, and 2.51, and to Microsoft C Compiler
 version 6.00 for MS-DOS.

 The problem lies in GRAPHICS.LIB, which is essentially the same for
 all the above mentioned products. Some calls to this library will
 incorrectly reset the color palette. This is a minor hardware
 incompatibility with the Magnavox VGA Adapter and there is currently
 no workaround.

 For a related article concerning the C product line, query the
 Microsoft Knowledge Base using the following words:

      Magnavox and setvideomode


 294. QuickPascal Uses Radians, Not Degrees, for Sin and Cos

 Product Version(s): 1.00
 Operating System:   MS-DOS
 Flags: ENDUSER | SR# S901231-66
 Last Modified: 14-FEB-1991    ArticleIdent: Q69163

 You must pass angle measurements in radians (not degrees) to Microsoft
 QuickPascal's Sin and Cos functions.

 Microsoft QuickPascal version 1.00 uses radians for its trigonometric
 functions (Sin and Cos); therefore, the value from QuickPascal will be
 different from a calculator's value for sine and cosine, unless your
 calculator is using radians.

 To convert degrees to radians, multiply the degrees by pi/180, where
 pi equals approximately 3.14159265359.

 Note: Pi is an intrinsic function than returns the value of pi in
 QuickPascal. See the online Help in QP.EXE for more information (by
 placing the cursor on the word "pi" in QP.EXE and pressing the F1
 function key).

 The following sample QuickPascal program shows how to convert degrees
 to radians:

 program convert(input,output);
  var
       x:integer; y:real;
   begin
       x:=45;
   writeln('sin of 45 radians =', sin(x));
   writeln('sin of 45 degrees =', sin(x*pi/180));
   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 [phone] 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 [phone].

 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 [phone].


 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 [phone].


 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 [phone]. Logitech
 also has a bulletin board service, which may contain the latest driver
 and can be reached at [phone].

 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 [phone] 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 [phone] 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 [phone].

 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 [phone]. 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 [phone].

 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 [phone].

 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 [phone].

 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