FIX: MASM BELL and SNAP TSR Program Examples Incorrect

Last reviewed: September 16, 1997
Article ID: Q85877
6.00 6.00a 6.00b | 6.00 6.00a 6.00b
MS-DOS           | OS/2
kbtool kbfixlist kbbuglist

The information in this article applies to:

  • Microsoft Macro Assembler for MS-DOS, versions 6.0, 6.0a, and 6.0b
  • Microsoft Macro Assembler for OS/2, versions 6.0, 6.0a, and 6.0b

SYMPTOMS

The BELL and SNAP TSR (terminate-and-stay-resident) sample programs that ship with the Microsoft Macro Assembler (MASM) versions 6.0, 6.0a, and 6.0b are not correct. Because of the errors in this program, other programs that are executed after the BELL or SNAP TSR program has been installed may hang the computer.

CAUSE

Because of the segment ordering and the way memory is released when the BELL or SNAP TSR program goes resident, the BeepCount variable is being freed. Because this variable is changed in the interrupt service routine (ISR), any program that is run after the BELL or SNAP TSR program has gone resident may have its memory corrupted.

RESOLUTION

To keep BeepCount from being released when BELL.EXE or SNAP.EXE terminates and goes resident, use one of the following solutions:

  • Change the class of the installcode segment so the segments are ordered correctly. In INSTALL.ASM and HANDLERS.ASM, a segment named installcode is declared with class CODE2, and is grouped inside DGROUP. Because both the assembler and linker treat class CODE2 the same as class CODE, and BELL.C and SNAP.C use .DOSSEG segment ordering, this code segment is placed prior to the data segments in DGROUP. If this segment is placed after the _DATA segment, where BeepCount is stored, the problem does not occur. To order the segments differently, change the class of installcode to class CODE2 in both INSTALL.ASM and HANDLERS.ASM. Class CODE2 is not treated the same as class CODE so the installcode segment will not be considered a code segment.

    -or-

  • Move BeepCount so that it isn't released when the BELL or SNAP TSR program terminates and goes resident. This can be accomplished by changing the declaration of BeepCount in BELL.C or SNAP.C to the following:

       int _based("CODE") BeepCount = 1;
    
       This will move BeepCount into the code segment where it will not
       be returned to MS-DOS. (Compile this code with Microsoft C
       version 6.0 or later.)
    
    

STATUS

Microsoft has confirmed this to be a problem in MASM versions 6.0, 6.0a, and 6.0b. This problem was corrected in MASM for MS-DOS version 6.1.

MORE INFORMATION

In MASM 6.0, this program also generates the run-time error:

   R6001 - null pointer assignment

This particular problem was corrected in MASM 6.0a and 6.0b by stubbing out the function that checked for null pointer assignments. The R6001 error also occurs because of segment ordering and can be corrected with the first solution above.

For more information on this problem, please see the following article in the Microsoft Knowledge Base:

   ARTICLE-ID: Q76945
   TITLE     : FIX: Sample Program BELL.C Causes R6001 Error


Additional reference words: 6.00 6.00a 6.00b
KBCategory: kbtool kbfixlist kbbuglist
KBSubcategory: CodeSam
Solution Type : kbfix


THE INFORMATION PROVIDED IN THE MICROSOFT KNOWLEDGE BASE IS PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND. MICROSOFT DISCLAIMS ALL WARRANTIES, EITHER EXPRESS OR IMPLIED, INCLUDING THE WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. IN NO EVENT SHALL MICROSOFT CORPORATION OR ITS SUPPLIERS BE LIABLE FOR ANY DAMAGES WHATSOEVER INCLUDING DIRECT, INDIRECT, INCIDENTAL, CONSEQUENTIAL, LOSS OF BUSINESS PROFITS OR SPECIAL DAMAGES, EVEN IF MICROSOFT CORPORATION OR ITS SUPPLIERS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. SOME STATES DO NOT ALLOW THE EXCLUSION OR LIMITATION OF LIABILITY FOR CONSEQUENTIAL OR INCIDENTAL DAMAGES SO THE FOREGOING LIMITATION MAY NOT APPLY.

Last reviewed: September 16, 1997
© 1998 Microsoft Corporation. All rights reserved. Terms of Use.