README.TXT (3.01)


BoundsChecker 3.01 Release Notes




-----------------------------------------------------------------
                        Table Of Contents 
-----------------------------------------------------------------
* Introducing BoundsChecker 3.0
* What's New In This Release
* Bugs Fixed
* Reporting Problems And Suggestions
* Prerequisites
* Installation
* If You Have A Previous Version Of BoundsChecker On Your System
* Removing An Installation
* Setting Up Help File References
* Known Anomalies
* Documentation Errata
* Technical Notes
* Rerunning The Tutorial
* Differences Between Quick, Normal And Maximum Modes
* Using BoundsChecker With Visual Test 4.0
* Using BoundsChecker With Symantec 7.0
* Using BoundsChecker With Watcom 10.5
* Adding BoundsChecker Tools To Visual C++ 2.0




Introducing BoundsChecker 3.0
-----------------------------

BoundsChecker 3.0 is available in two editions: Standard and 
Professional.

BoundsChecker Standard Edition combines Nu-Mega's award-winning 
automatic bug detection technology, improved ease-of-use and new error 
suppression technology that lets you decide what parts of your 
application to check and prevent error reports when they don't apply to 
your part of the project. 

BoundsChecker Professional Edition features all of the new technology 
and ease-of-use of the Standard Edition, plus the ability to find over 
three times more bugs by inserting error detection code at compile time. 
This process is called compile-time instrumentation. Review 
"Descriptions of Errors BoundsChecker Detects" in the BoundsChecker on-
line help for details.

NOTE: Only one BoundsChecker edition (Standard or Professional) can be 
installed on your system.

BoundsChecker 3.0 is integrated with Microsoft Visual C++ (2.1 and 
later) to make it easy to build your project with instrumentation. You 
can even run without instrumenting for quick checks every time you make 
a change to your code. Just press the BoundsChecker button to run 
directly from Visual C++. We think you'll agree that our new look and 
feel, along with our advanced error detection features make this the 
best BoundsChecker yet.

For a quick run with BoundsChecker, read the Tutorial in the 
Introduction to BoundsChecker manual, and try checking the programs in 
the EXAMPLES directory. The TUTORIAL example takes you step-by-step 
through your first bug checking session. BUGBENCH demonstrates all the 
errors we can catch, and requires Windows NT 3.51 or Windows 95. Windows 
NT 3.5 users can build and run the programs in EXAMPLES\TESTW32. 
TESTW32.EXE causes errors that are detected without using compile-time 
instrumentation, while TESTW32I.EXE is built with instrumentation and 
lets BoundsChecker detect even more bugs.




What's New In This Release
--------------------------

--- More control: BoundsChecker 3.0 gives you more control over which 
parts of your program to check for bugs. You can use the Settings dialog 
to specify:
   - DLLs to be checked
   - Whether or not the EXE should be checked
   - Source files to be checked

--- More reliable error reporting: You can prevent BoundsChecker from 
reporting errors in modules that were not compiled with debug 
information. Quick mode will not report on this type of error, but 
Normal and Maximum modes will. In Custom mode, use the Reporting option 
'Report errors even if no source code is available' to control this 
feature.

--- Suppressing errors: Our new error suppression technology lets you 
mark errors that you do not wish to examine at this time. You can 
suppress errors for the current run, or save the suppressions for future 
runs. Use this new feature to temporarily ignore errors that are not 
your responsibility, or to permanently suppress errors for third party 
libraries or for special coding situations which may be detected as 
errors, but are actually correct behavior.

--- Integration with Microsoft Visual C++ 2.1, 2.2 and 4.0: 
BoundsChecker has been fully tested with the final release of Visual C++ 
4.0.

--- Integration with Microsoft Visual Test 4.0: BoundsChecker is also 
integrated with Visual Test 4.0. See the BoundsChecker or Visual Test 
on-line help for more information.

--- Ability to run multiple instances of BoundsChecker: It is now 
possible to launch multiple instances of BoundsChecker. This is 
especially useful in testing OLE applications.

--- BoundsChecker return values: BoundsChecker now returns the following 
result codes:
   0 - The application ran and there were no errors generated
   1 - The application ran and there are errors in the error log
   2 - Unable to start the specified application

--- New instrumentation error message:
"** Error detected in template... this code may not be processed by your 
normal compiler"
This message will follow any compilation error occurring inside a 
template definition. Syntax errors in templates are not reported by 
Visual C++ if the template is never used, but such a template error is 
an obstacle to instrumentation. However, the message does not imply that 
the template is never used. (Professional Edition Only)



Bugs Fixed
----------

The following bugs are fixed in this release:

--- Many SQL routines are now checked correctly, including: 
SQLNumResultCols, SQLGetInfo, SQLDriverConnect, SQLNumResultCols, 
SQLDescribeCol.
--- BoundsChecker no longer reports resource leaks on call to 
GetMetaFileBitsEx and GetEnhMetaFileBits.
--- GetQueuedCompletionStatus no longer produces a bogus memory 
overwrite
--- Linker errors caused as a side effect of instrumentation
--- Many miscellaneous instrumentation failures
--- New data types supported: _int8, _int16, _int32, _int64
--- Externs in procedure scope are handled correctly.
--- Proper use of pchdir for precompiled header file.
--- BoundsChecker correctly compiles types of the following format: 
typedef int (__stdcall COMESCAPE (int, int ))
--- BoundsChecker correctly uses the CL environment variable




Reporting Problems And Suggestions
----------------------------------

Technical Support is available by e-mail at support@numega.com or by 
calling Technical Support at 603-889-2386. You can also FAX us at 603-
889-1135 (attention: Technical Support).

Problem reports should include:

- System Configuration (O/S, MSVC version, processor, RAM)
- Detailed problem description (include exact error message text)
- How to reproduce problem
- Whether you are compiling from C++ IDE or command line
- Options used in compiling and linking
- Your error detection mode (Quick, Normal, Max or Custom)




Prerequisites
-------------

Note: The BoundsChecker setup disks are designed for a specific 
operating system (Windows NT or Windows 95). Make sure you have 
purchased the correct version for your operating system.

* PC-compatible 486 system or above
* Microsoft Windows NT 3.5 or 3.5.1 or
  Microsoft Windows 95
* 24 MB RAM recommended (Professional Edition)
* 16 MB RAM recommended (Standard Edition)
* approximately 9 MB free disk space for full installation
  (6.2 MB required if installed without examples and tutorial)
* Compile-time Instrumentation (available only with BoundsChecker 
Professional Edition) requires Microsoft Visual C++ 2.1 or later

NOT SUPPORTED BY THIS RELEASE:
* Microsoft NewShell preview under Windows NT 3.51: NewShell preview 
software for Windows NT 3.51 is not supported. Microsoft strongly 
recommends that "this shell not be used in a production environment, and 
it should be removed before installing Visual C++ 4.0."




Installation
------------

To install BoundsChecker 3.0, insert Disk 1. Close Microsoft Visual C++, 
if running. From the Windows NT Program Manager or File Manager, run the 
Setup program from Disk 1. On Windows 95, use the Add/Remove Programs 
Control Panel applet.

Follow the prompts. Setup copies all BoundsChecker files to the 
destination directory, updates the Windows registry, and creates the 
BoundsChecker 3.0 program group.

NOTE: If you are using Microsoft Visual C++ 2.0, BoundsChecker tools 
will NOT be added to the IDE Tools menu. See below for instructions on 
adding the tools to Visual C++ 2.0.

NOTE: BoundsChecker expects that you have already set up the environment 
required by Visual C++. Normally this is done when you install Visual 
C++. You need these environment strings (assuming your Visual C++ 
installation is c:\msvc):
	include=c:\msvc\include;c:\msvc\mfc\include
	init=c:\msvc
	lib=c:\msvc\lib;c:\msvc\mfc\lib
	path=c:\msvc\bin

The BoundsChecker installation directory needs to be in your path if you 
plan to compile and link from the DOS command line.




If You Have A Previous Version Of BoundsChecker On Your System
--------------------------------------------------------------

BoundsChecker32/NT or BoundsChecker for Windows 95: BCHK32NT and/or 
BCHK32C must not appear in the path before the BoundsChecker directory. 
If they do, BoundsChecker may crash or fail to detect errors because it 
is trying to load obsolete libraries from the earlier product.

BoundsChecker 3.0: If you have customized ROUTINE.DAT, be aware that 
this file has been updated and renamed to DEFAULT.DAT, and is located in 
the BoundsChecker DATA sub-directory. You will need to re-enter your 
changes in a new copy of ROUTINE.DAT.




Removing An Installation
------------------------

To remove this product, run the Remove BoundsChecker program item.

"Remove" performs these steps:
- Deletes BoundsChecker files from the BoundsChecker installation 
directory and sub-directories.
Note: Files that you created after installation (e.g. Help system GID 
files) are not deleted.
- Deletes Visual C++ and Visual Test support files.
- Removes BoundsChecker registry entries
- Removes BoundsChecker specific Visual C++ and Visual Test registry 
entries
- Deletes the BoundsChecker 3.0 program folder and items




Setting Up Help File References
-------------------------------

Setup tries to locate some of the help files shipped with Microsoft 
Visual C++ 2.x. If Setup cannot find them, you will be prompted for 
their locations. If you do not know their names at installation, you can 
add these values later to the registry under the key:

HKEY_CURRENT_USER\Software\Nu-Mega\BoundsCheckerPro\Help

Include a full path and enter any of the following values:

NAME      TYPE    DATA
C         REG_SZ  Cxx20.HLP
Cruntime  REG_SZ  CRT20.HLP
MFC       REG_SZ  MFC30.HLP
Win32     REG_SZ  AP132.HLP

For example:

C:\MSVC20\HELP\Cxx20.HLP

If you have Visual C++ 4.0 installed (and do not have Visual C++ 2.x 
installed), Setup will be unable to locate the help files. This is 
because Visual C++ 4.0 no longer ships this information in the form of 
Windows Help files. Rather, they are shipped as InfoViewer files. Future 
releases of BoundsChecker will accommodate this change.




Known Anomalies
---------------

--- BoundsChecker reports leakage when processing DLL_PROCESS_DETACH. 
Since the order in which modules are unloaded cannot be controlled, 
erroneous leakage reports can result when a DLL unloads after 
BoundsChecker. This can occur when the following conditions are met:
- user DLL allocates memory in DLL_PROCESS_ATTACH
- user DLL frees the allocated memory in DLL_PROCESS_DETACH
- BoundsChecker unloads before the user DLL

--- If BCBUILD cannot create the debug directory (because it already 
exists) and causes nmake to fail, add the /N switch as the first 
argument (before the existing /f switch) to the BCBUILD command in the 
registry. The following keys are affected (Visual C++ 2.2):
HKEY_CURRENT_USER/Software/Microsoft/Visual C++ 2.0/BoundsChecker
  Argument3 = '/N /f "$Proj" /t "%e" /B -2'
HKEY_CURRENT_USER/Software/Microsoft/Visual C++ 2.0/BoundsChecker
  Argument4 = '/N /f "$Proj" /t "%e" /R -2'
Or (Visual C++ 4.0):
HKEY_CURRENT_USER/Software/Microsoft/Developer/BoundsChecker
  Argument3 = '/N /f "$(WkspDir)\$(WkspName).mak" /t "%e" /c "%c" /B -4'
HKEY_CURRENT_USER/Software/Microsoft/Developer/BoundsChecker
  Argument4 = '/N /f "$(WkspDir)\$(WkspName).mak" /t "%e" /c "%c" /R -4'
(This problem is known to affect 4DOS/NT users.)

--- Visual C++ IDE command line settings (from the Settings dialog) will 
override BoundsChecker specific command line settings. If your project 
requires command line settings, make sure they are set correctly in both 
Visual C++ and BoundsChecker.

--- Installing BoundsChecker into a directory using long file names may 
cause problems with the Visual C++ integration. Use short (8.3) names 
for install directories, if possible.

--- The example program BugBench will not run under Windows NT 3.5. It 
requires Windows NT 3.51 or Windows 95. Windows NT 3.5 users can 
instrument and check TESTW32 in the EXAMPLES directory.

--- BoundsChecker does not automatically update all dependencies if your 
.MAK file contains a different source path than the actual location of 
your files. To correct this, select Project, and Update All Dependencies 
before running BoundsChecker Build or Rebuild All. (Professional Edition 
Only)

--- BoundsChecker will use your IDE Options settings for include file 
and library directories. If you change these settings, you must close 
the IDE and reopen it to cause BoundsChecker to pick up the changes. 
(Professional Edition Only)

--- Running an instrumented program under the Visual C++ debugger may 
cause the message 'Target out of date' to appear. This is normal Visual 
C++ behavior. Visual C++ considers a target to be out of date if the 
project has never been built with CL from the IDE (for example, if you 
normally build with CL from the DOS command line). The message also 
occurs after changing any of the project settings, and starting the 
debugger before rebuilding with CL from the IDE. The message is 
harmless, and you do not have to rebuild your project with BoundsChecker 
before debugging. (Professional Edition Only)

--- If you re-install Visual C++, the registry options used for 
BoundsChecker IDE integration are lost. To restore them, run 
BoundsChecker Setup, select Custom installation, and check only Visual 
C++ support.

--- Program settings are keyed to an EXE name. If you are building a DLL 
in the Visual C++ IDE, set the project "Executable for Debug Sessions" 
to the fully qualified EXE name before setting BoundsChecker Error 
Detection Settings. The EXE and the DLL will share the same settings.

--- In some instances, BoundsChecker may compile a file that you do not 
think is in your project. Due to the way Visual C++ writes its 
automatically generated MAK files, there is a rare instance in which 
running NMAKE on the project MAK file compiles different files than 
selecting the Build command from the IDE. The problem occurs when the 
project contains a .cpp file (example test.cpp) and there is a junk file 
in the same directory named test.c. The IDE build will build test.cpp, 
but BoundsChecker will build test.c. A similar problem happens if a 
project contains test.cxx, and there are junk files named test.cpp or 
test.c. The solution is to remove or delete the junk file. This occurs 
because BoundsChecker uses NMAKE to build, while the IDE uses its own 
internal make procedure. (Professional Edition Only)

--- Under Windows 95, you must specify command.com as your comspec if 
you perform BoundsChecker Build or Rebuild All under the Visual C++ IDE. 
Using 4DOS version 5.0f will result in a compilation error because 4DOS 
does not pass all command line arguments to the BoundsChecker build 
procedure. (Professional Edition Only)

--- BoundsChecker cannot load programs without an idata section.

--- In some rare instances, BoundsChecker may falsely report an 
incorrect number of arguments for sprintf functions for optimized code. 
Use Suppress to prevent a false report on later runs.

--- Leaks in externally loaded DLLs may not be detected in Quick mode. 
This is because Quick mode only reports errors in modules that have 
source code available. If a DLL is unloaded before BoundsChecker 
performs leak reporting, the symbol information that BoundsChecker uses 
to find the source code is not available.

--- In some unusual cases, projects that use /YX may get the following 
error during instrumentation after being built with CL first:

    error C2143: syntax error : missing ';' before 'newline'

This appears to be caused by a bug in CL involving the use of 
precompiled headers and the /YX option. To solve the problem, either 
delete vc20.pch before instrumenting, or do not compile with /YX. 
(Professional Edition Only)




Documentation Errata
--------------------

BoundsChecker Users Guide (Professional and Standard Editions):

--- Page D-4: Ignore the listing showing the contents of the default 
ROUTINE.DAT file. The listing is actually an incomplete listing of the 
contents of the DEFAULT.DAT file.

--- Table 3-1: "function_ignore" is shown on a separate line from 
"filename::function-name". However, they need to be on the same line in 
the option file passed to BCOMPILE with the -Zop option. Include a 
complete command line for each function to be ignored.

Example:
function_ignore myfile.cpp:MyFunction

--- Table 3-1: "expand" is shown on a separate line from "structure-
name.array-name". However, they need to be on the same line in the 
option file passed to BCOMPILE with the -Zop option. Expand is used to 
prevent error reports for structures in which the last element is an 
array whose size is determined at run-time.

Example:
For array data declared like this:
struct stretchy {
     int nvals;
     int data[1];

use this option command:
expand struct stretchy.data




Technical Notes
---------------

Halting a Program: 'Halt' on the BoundsChecker Program menu lets you 
force an ill-behaved program to terminate. When you use this feature, 
the event log may not be complete since termination takes effect 
immediately. This function should only be used when all other methods 
fail. The preferred ways to end a program are: 1) Close the program from 
its own menu; 2) if BoundsChecker detects an error, press Halt on the 
Program Error Detected window; or 3) End the program from the operating 
system task manager.

Preventing Leaks in DLL Startup Code: BoundsChecker will detect leaks 
from the initialization code of a DLL that you cannot correct. To 
prevent these reports, name your DLL entry point DllMain. BoundsChecker 
recognizes DllMain, and knows not to check the startup code.

Compliance Checking: BoundsChecker provides two kinds of Win32 
compliance checking--Comprehensive and Last Run. Comprehensive checking 
examines your entire EXE file for API calls, while Last Run checking 
only looks at the calls that were actually executed when you ran your 
program under BoundsChecker. Comprehensive checking does not examine API 
calls made by any DLLs used by your EXE. Last Run checking looks at the 
EXEs calls as well as API calls made by DLLs we watched. If your code 
was generated with /MD (multithreaded using DLL), we also report ANSI C 
calls.

APICheck for ANSI C Functions: BoundsChecker can check ANSI C API calls 
for bad parameters and returns and log these calls in the event viewer. 
Your program must link dynamically to the C runtime library to enable 
this checking. Build your program with the /MD option, or set your C++ 
Code Generation setting in Visual C++ to "Multithreaded using DLL".

Debugging Instrumented Programs (Professional Edition Only): When you 
use the Visual C++ debugger on an instrumented file, you will be 
prompted for the source file for NONAME. This refers to parts of the 
instrumented code that are not part of the original source file. Source 
is not available for this code. Press CANCEL if the prompt for NONAME 
appears, and continue debugging your program. Also note that stepping 
through instrumented code in the debugger can cause the execution 
pointer to appear to move non-sequentially through your source code. 
This is normal behavior due to the additional code inserted during the 
instrumentation process.

Detecting Leaks in Partially Instrumented Applications (Professional 
Edition Only): If a pointer is created in code that you instrumented, 
and then passed to a function that is not instrumented, BoundsChecker 
will not detect if this pointer is leaked. An example of this is a 
pointer created in an instrumented EXE that is passed to an un-
instrumented DLL. Any time a pointer is passed to a "foreign" function, 
we consider it nonleakable, as that function may have saved the pointer. 
"Foreign" is defined here as a function which wasn't processed by 
BCOMPILE, isn't already understood by BoundsChecker, and isn't listed in 
the bcompile.def file.

Detecting "Memory leaked leaving scope" (Professional Edition Only): 
When instrumentation detects a leak due to a function exiting, we delay 
reporting the error until after the function returns. The error window 
will show the line that calls the function with the leak. This avoids 
possible false reports from C++ code if constructors for local variables 
get called as the function exits, since these events take place after 
the entire function has completed. The report of the leak needs to be 
delayed until after the function actually calls its destructors, to 
avoid reporting a leak for something the destructor may free. In the 
case when a scope exits, but the function does not, we check for any 
local leaks on variables inside that scope and report it at the point 
where it happens.

Debugging an NT service: Using the Registry Editor (REGEDIT.EXE), go to 
HKEY_LOCAL_MACHINE\SOFTWARE\MICROSOFT\WINDOWS NT\CurrentVersion\. Create 
a new key called "Image File Execution Options". Under this key, create 
a subkey with the name of your service. For example, MYSERV.EXE. To this 
subkey, add a REG_SZ value called Debuggger. For the Debugger value, 
enter the path to the BoundsChecker program (e.g., 
C:\BCProNT\BCPRO.EXE). Exit the Registry Editor. Start up the Control 
Panel, and double-click on the 'Services' icon. Highlight your service 
to be checked. Click the 'Startup...' button. In the dialog box that 
appears, select the 'Allow Service to Interact with Desktop' button. 
Click OK. If you don't do these steps, BoundsChecker will run, but will 
be invisible. At the main Control Panel | Services dialog, start your 
service. BoundsChecker should appear, with the service already opened. 
At this point, you can set any desired options and then run the service 
via BoundsChecker. If your service starts automatically during NT's 
bootup, use the Control Panel to set the 'Interact with desktop' 
attribute, and then restart the machine. BoundsChecker should start 
automatically when the service is started. (IMPORTANT NOTE: This only 
works with Windows NT 3.51, or with checked builds of 3.50!)

Automatically invoking BoundsChecker when a program is executed (Windows 
NT only): You would use this if the program is invoked by some other 
process, and you want to run BoundsChecker on this program. NOTE: This 
works only on Windows NT, and will not work on Windows 95. As always, be 
careful whenever you edit the registry. Using REGEDT32:
1. Select the key
  HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion
2. Under the selected key, add the following KEY, if it does not exist:
  Image File Execution Options
3. Under "Image File Execution Options" add this KEY:
  FOO.EXE
  (where FOO.EXE is the name of the program you want to test.)
4. Under the "FOO.EXE" key add a new VALUE:
  Value name: Debugger
  Data type:  REG_SZ
  String:     c:\bcpront\bcpro.exe
  (Where the string value is the full pathname for BoundsChecker on your 
machine.)

Startup performance and alternate DEFAULT.DAT files: If your program 
takes an unusually long time to start under BoundsChecker, you may want 
to use one of the alternate DEFAULT.DAT files shipped with 
BoundsChecker. First, rename DEFAULT.DAT (in the BoundsChecker DATA 
directory) to DEFAULT.BAK. Then, copy one of the alternate DEFAULT files 
to DEFAULT.DAT. If your program is compiled with Borland, use 
DEFAULT.BOR. If your program is compliled with Microsoft, use 
DEFAULT.MSC.




Rerunning The Tutorial
----------------------

If youve run the tutorial and need to start the tutorial from the 
beginning, perform the following steps to reset the tutorial to its 
shipping state:

1)  Rebuild the tutorial project using the Microsoft compiler instead of 
BoundsChecker
- From Visual C++, open the Tutorial project, then choose Rebuild 
All from the Project menu

2) Change the error detection level to Quick mode
- Choose BoundsChecker Settings from the Tools menu
- Press Error Detection
- Choose Quick, then press OK

3) Reset the DLLs to check settings
- From the Settings dialog, click the Files tab
- Press Select DLLs
- Check FILER.DLL, then press OK

4) Reset the source file selection
- From the Settings dialog, press Select Source Files
- Click on Check All Source Files, then press OK

5) Save all the changes
- Press OK in the Settings dialog

You can now restart the tutorial.




Differences Between Quick, Normal And Maximum Modes
---------------------------------------------------

Quick mode is designed to give you significant error detection and fast 
run-time performance. It avoids reporting errors that you may not be 
able to do anything about, so it only reports errors that have source 
code available (i.e. in modules that were built with debug information). 
If a line of code causes more than one error (for example, a bad API 
parameter that causes an API return failure), only the first error is 
shown. If an error occurs in a loop, BoundsChecker only reports the 
error the first time it occurs. We don't check string lengths on 
parameters to API calls, although we still check lengths for string 
functions. Quick mode collects only error information, and does not 
create an event log or save call stacks for leaks.

Normal mode adds API return checking, more guard bytes for overrun 
checking, call stack traces, and creates an event log. It will show 
errors even if no source is available. Like Quick mode, Normal mode 
shows you only the first error at each location. 

Maximum mode gives you everything that Normal mode does. It also checks 
for overruns on each API call, adds more guard bytes, and reports all 
errors associated with a line of code.

When you use instrumentation in Quick mode, checks for uninitialized 
pointers are inserted in your code. For more instrumentation checking, 
select BoundsChecker Settings from the IDE tools menu and change Error 
Detection to Normal or Maximum mode. In these modes, uninitialized 
memory checks are inserted for all locals, globals, and static memory 
using a pattern matching algorithm.




Using BoundsChecker With Visual Test 4.0
----------------------------------------

BoundsChecker and Visual Test

When using the BoundsChecker with Visual Test, make sure that your 
scripts wait for BoundsChecker to completely finish so all text is 
properly sent to your BoundsCheckerNotification handler.  If the script 
ends before BoundsChecker is finished, some error notifications might 
not get through.  This is especially true with memory and resource leaks 
since the application being tested must completely end before they can 
be reported.

Here are two methods to make sure your script does not end prematurely:

1.  In the test script, following the commands to close the application 
being tested, add a long enough sleep statement to allow BoundsChecker 
to get all the information over to the notification handler (You may 
need to use a value greater than the 60 used here).
...
WSysMenu ( 0 )
WMenuSelect ( "&Close" )
Sleep ( 60 )
End
...

2.  If the script is run interactively, a Pause statement will display a 
message box and wait until the OK button is pressed before the script 
will continue.





Using BoundsChecker With Symantec 7.0
-------------------------------------

The Symantec C\C++ compiler uses the Microsoft Codeview debug format, so 
no special steps need to be taken during compile and link except to 
include debug information. This can be accomplished by compiling and 
linking with the following switches:

Compile: -g
Link: /CO

As with any debugger, BoundsChecker works best if optimizations are 
disabled, which can be done by compiling with the -od compiler switch.

The Symantec C\C++ compiler also uses the MFC class library. This is the 
same MFC as is shipped with the Microsoft Visual C++ compiler. 
BoundsChecker works the same with both the Microsoft and the Symantec 
compilers.




Using BoundsChecker With Watcom 10.5
------------------------------------

The Watcom 10.5 compiler is capable of producing Codeview compatible 
debug information and thus is compatible with BoundsChecker.  
BoundsChecker will not run correctly with versions of Watcom prior to 
10.5. However, some problems have been found running Watcom compiled 
programs under BoundsChecker.  Because of these problems, there is no 
guarantee how well BoundsChecker will perform.  Nu-Mega Technologies has 
done everything it can to provide the best possible compatibility with 
Watcom C\C++.  Following is a list of things that must be done in order 
for BoundsChecker to work properly with Watcom 10.5 and known anomalies 
when running Watcom compiled programs.

1) PRODUCE CODEVIEW COMPATIBLE DEBUG INFORMATION
To do this with the compiler ( WCC386.EXE ) use the following switches:
-hc -d3
-hc - Set output debug format - Codeview.
-d3 - Full symbolic debugging with unreferenced type names.

For the linker, include the line:  DEBUG CODEVIEW

2) DISABLE OPTIMIZATIONS
Use the -od compiler switch to do this. If optimizations are not 
disabled, then Watcom will produce inline assembly for calls to C-Lib 
functions like strcpy(). In this case BoundsChecker cannot perform 
correctly. Versions of Watcom prior to 10.5 would not allow this 
optimization to be turned off, prohibiting BoundsChecker from working.

3) USE STACK CALLING CONVENTIONS
BoundsChecker looks at the stack for parameters passed to C-Lib 
functions. If these parameters are not present, BoundsChecker cannot 
perform properly. In order to force the Watcom compiler to use stack 
calling conventions, use either the -3s, -4s or -5s compiler switch.

4) CVPACK THE EXECUTABLE
After building the .EXE file, run CVPACK, found in the Watcom BINNT 
directory, on the .EXE. This will arrange the debug information into a 
format that BoundsChecker can read.

5) INSTRUMENTING A WATCOM PROGRAM
Because the Watcom compiler uses different switches than Microsoft, 
Watcom programs cannot be instrumented. This is a possible future 
enhancement.

6) MODIFY ROUTINE.DAT
Add the following lines to ROUTINE.DAT in the BoundsChecker data 
directory. This will allow BoundsChecker to track calls to new and 
delete.

;Watcom new []
W?$nan(ui)pnv ID 011

;Watcom delete []
W?$dan(pnv)v ID 019

;Watcom new
W?$nwn(ui)pnv ID 011

;Watcom delete
W?$dln(pnv)v ID 019

7) KNOWN PROBLEMS
Watcom's compiler pre-allocates memory blocks (using LocalAlloc) to be 
used with calls to _malloc. All calls to _malloc are sub-allocated from 
these pre-allocated blocks. Because of this sub-allocation, 
BoundsChecker is unable to check _malloc() blocks correctly. To get 
around this problem, suppress LocalAlloc call checking in the Error 
Suppression dialog (LocalAlloc is located in KERNEL32.DLL).




Adding BoundsChecker Tools To Visual C++ 2.0
--------------------------------------------

If you are running BoundsChecker with Visual C++ 2.0, you may want to 
add the BoundsChecker Tools to the Visual C++ 2.0 Tools menu, since 
Setup does not automatically do this for you.

Visual C 2.0 users lose three features that are available for Visual C 
2.1 and 2.2 users:

- Passing the working directory to BoundsChecker from Project Settings
- Passing arguments to BoundsChecker from Project Settings
- Passing the EXE name from Project Settings when building a DLL

Follow the instructions below. (Substitute the directory in which you 
installed BoundsChecker for c:\bcproNT in the following examples).

Items 1 and 2 are used with BoundsChecker Professional and Standard 
Editions. Items 3 through 5 are used with BoundsChecker Professional 
Edition only.

1) Add BoundsChecker
a) Pick Tools-Customize. Then select the Tools page.
b) Click Add. Command: c:\bcproNT\bcpro.exe
   Click OK.
c) Enter these items:
MenuText: BoundsChecker
Arguments: /IIDE /m /l "$Target"

2) Add BoundsChecker Settings...
a) Click Add. Command: c:\bcproNT\bcpro.exe
   Click OK.
c) Enter these items:
MenuText: BoundsChecker Settings...
Arguments: /IIDE /O "$Target"

3) Add BoundsChecker Build (Professional Edition Only)
a) Click Add. Command: c:\bcproNT\bcbuild.exe
   Click OK.
c) Enter these items:
MenuText: BoundsChecker Build
Arguments: /f "$Proj" /t "$Target" /B -2
Check "Redirect to Output Window"

4) Add BoundsChecker Rebuild All (Professional Edition Only)
a) Click Add. Command: c:\bcproNT\bcbuild.exe
   Click OK.
c) Enter these items:
MenuText: BoundsChecker Rebuild All
Arguments: /f "$Proj" /t "$Target" /R -2
Check "Redirect to Output Window"

5) Add BoundsChecker Stop Build (Professional Edition Only)
a) Click Add. Command: c:\bcproNT\bcstop.exe
   Click OK.
c) Enter these items:
MenuText: BoundsChecker Stop Build
Arguments: <none>
Check "Redirect to Output Window"




-----------------------------------------------------------------
Copyright 1995 Nu-Mega Technologies, Inc.
Portions provided by ParaSoft Corporation.
12/4/95
