📄 readme.bc
字号:
mode conflict with BOUNDS-CHECKER.
-------------------------------------------------------------------
13. BORLAND PROGRAMS WITH LESS THAN 8K STACKS
-------------------------------------------------------------------
Problem: On Borland programs with less than 8K stack space, the
/V4K switch relocates the stack incorrectly.
Solution: Do not use the /V4K switch when the stack size is less
than 8K.
-------------------------------------------------------------------
14. RUNNING WITH DR-DOS 6.0
-------------------------------------------------------------------
Problem: BOUNDS-CHECKER hangs when loaded.
Solution: Remove HIDOS.SYS from your CONFIG.SYS file; use a
commercial memory manager such as QEMM instead. Also, do not use
a HIBUFFERS statement in your CONFIG.SYS.
-------------------------------------------------------------------
15. USE OF "msize","fmsize" & "nmsize" FUNCTIONS
-------------------------------------------------------------------
When allocation checking is enabled, BOUNDS-CHECKER adds two
bytes to the allocated block; the two bytes are set to AA and 55
hex. When the block is freed, BOUNDS-CHECKER reads these bytes to
verify that they have not been overwritten.
The "msize", "fmsize" and "nmsize" functions return the size of
an allocated block rounded up to the next word (allocations always
start on word boundaries, so this will not infringe on the next
block). If one of these functions is used on a block allocated when
running BOUNDS-CHECKER, the size returned includes the two bytes
added by BOUNDS-CHECKER, besides being rounded up to the next word.
If this size is used to copy data, it would transfer 2 more bytes
than expected, and BOUNDS-CHECKER would pop up indicating an
overrun.
This would apply as well to any other functions which return the
size of an allocated block.
-------------------------------------------------------------------
16. USING BOUNDS-CHECKER WITH METAGRAPHICS
-------------------------------------------------------------------
The Metagraphics libraries use two large data blocks in the code
area named GRAFIX_DATA and WINDOW_DATA. These libraries also make
direct calls to the mouse driver, and overwrite these blocks in the
code area from that driver, which causes BOUNDS-CHECKER to pop up
with a message that the code area is being overwritten from outside
the program. A side effect of this is that some of the mouse data
may get lost when BOUNDS-CHECKER comes up, which puts the mouse out
of synch, and may lock up the system.
One way around this is to let anything access these blocks, so
that BOUNDS-CHECKER does not pop up. This section shows how to make
the appropriate entries in the exception file by reading the .MAP
file.
Below is part of a .MAP file, which shows these blocks in the
module list, and the corresponding labels in the Publics by Value
section.
Start Stop Length Name Class
00000H 000CDH 000CEH MNSAMP02_TEXT CODE
1A226H 1A822H 005FDH _CODE CODE
1A830H 1E171H 03942H GRAFIX_DATA CODE
1E172H 1F09FH 00F2EH GRAF_2 CODE
2B3CAH 2C72DH 01364H GRAF_5 CODE
2C730H 2CA01H 002D2H WINDOW_DATA CODE
2CA02H 2CDDEH 003DDH GRAF_6 CODE
Address Publics by Value
1A22:05E5 _WriteImage ;just before GRAFIX_DATA
1A83:0204 Meta_DPL
1A83:032C grafBMap
1A83:2F93 __mousLevel
1E17:0008 __GetBits ;just after GRAFIX_DATA
2B3C:12E0 __InceptRect ;just before WINDOW_DATA
2CA0:0002 __Gbl2UsrP ;just after WINDOW_DATA
Below is the exception file made from the .MAP file above; notice
that it uses labels which span these two areas so that anything can
access them. It also includes entries for other common exceptions
from Metagraphics libraries.
ACCESS ANYONE
{
_WriteImage __GetBits ;GRAFIX_DATA
__InceptRect __Gbl2UsrP ;WINDOW_DATA
}
ACCESS ANYONE
{
00040H:00010H ; equipment flag
00040H:00017H ; keyboard flags (shift/ctrl/alt/lock)
}
ACCESS ANYONE
{
VIDEO
}
-------------------------------------------------------------------
17. OVERRUN OF BLOCK ALLOCATED BY BORLAND'S __OvrPrepare ROUTINE
-------------------------------------------------------------------
Problem: BOUNDS-CHECKER reports an overrun of a block that was
allocated by the routine __OvrPrepare.
Solution: Turn off Verbose alloc check. This overrun is caused
by a bug in Borlands VROOMM that actually does overrun their own
buffer (non-fatal, just a bug). The problem is that after BOUNDS-
CHECKER reports this error, it puts an end-of-buffer stamp in again
which overwrites code so the program will eventually fail.
Another solution is to edit the Borland OVERLAY.LIB file to
change the size of the allocated block, as follows:
debug overlay.lib
-s 0 lffff b8 10 00 f7 e3
(prints an address)
-e address b8 11 (changes decimal 16 to decimal 17)
-w
-q
After making this change, relink the application program so that
the modified library is contained within it.
-------------------------------------------------------------------
18. CSCAPE PROGRAM APPEARS TO HANG
-------------------------------------------------------------------
Problem: When a program containing the C-scape libraries is run
under BOUNDS-CHECKER, it appears to hang.
Solution: The C-scape libraries search the BIOS ROM to determine
if the PC is a Compaq. This results in BOUNDS-CHECKER adding many
entries to the exception file, so that it appears to hang. To avoid
this, put the following entry to the exception file before running:
ACCESS _pc_IsCompaq __oakint86
{
0FA00H:00000H 0FFFFH:00008H
}
-------------------------------------------------------------------
19. CTRL-ALT-DEL DOESN'T WORK
-------------------------------------------------------------------
Problem: Ctrl-Alt-Del won't reboot on IBM Model 55SX, Dell, DTK,
Northgate, AST and some other systems when BOUNDS-CHECKER is
running.
Solution: The keyboard controller on these systems does not
recognize the reboot command (send FE to port 64). To fix this,
change bchk.exe as follows:
ren bchk.exe bchk.bin
debug bchk.bin
-s 0 lffff b0 fe e6 64 bb
(prints 2 addresses in xxxx:yyyy format)
-e address1 90 90 90 90 bb 01
-e address2 90 90 90 90 bb 01
-w
-q
ren bchk.bin bchk.exe
-------------------------------------------------------------------
20. USING BCHK WITH SERIAL COMMUNICATIONS PROGRAMS
-------------------------------------------------------------------
Problem: BOUNDS-CHECKER traps all interrupts and reprograms the
Page Fault hardware before allowing the interrupt. This limits the
rate at which interrupts can occur without loss of data.
Solution: Configure BOUNDS-CHECKER for maximum performance:
1. If using Borland, enable both performance options.
2. Disable Verbose Data and Line options. If problems persist,
disable all data checking.
3. If using Microsoft, link in BC4.OBJ. If using Borland
create a 4K buffer at the beginning of your data segment.
4. Use the lowest baud rate possible.
5. Remove all unnecessary drivers and TSR's; one user reported
that removing 386MAX dramatically improved his communication rate.
6. Use the fastest machine available.
7. If possible, use a UART with a FIFO buffer chip.
-------------------------------------------------------------------
21. PCODE PROGRAMS
-------------------------------------------------------------------
BOUNDS-CHECKER has limitations with Microsoft C7 pcode programs:
1) The module that contains main can NOT be compiled with pcode.
2) BOUNDS-CHECKER will not show source in modules compiled with
pcode.
-------------------------------------------------------------------
22. USING FOREIGN KEYBOARDS
-------------------------------------------------------------------
BOUNDS-CHECKER supports only the US keyboard: however, in some
cases it is possible to patch it to allow using foreign keyboards.
There is a file named KEYBOARD.ZIP in the File Download section
of our BBS (USA-603-595-0386) that shows how to patch BCHK.EXE to
work with non-USA keyboards. The same file is available on Compu-
Serve (GO NUMEGA) under the name KEYBOA.ZIP.
-------------------------------------------------------------------
23. GRAPHICS APPLICATION PROGRAM RUNS VERY SLOWLY.
-------------------------------------------------------------------
Problem: Graphics-based application program runs very slowly
under BOUNDS-CHECKER.
Solution: Some programs run very slowly under BOUNDS-CHECKER
when an EMS memory manager is loaded. Apparently some graphics
libraries will use the EMS memory manager to access Upper Memory
Blocks, which causes BOUNDS-CHECKER to trap repeatedly, slowing
execution of the application program. EMM386 is the worst offender
in this regard, followed by QEMM. 386MAX and Soft-ICE have a lesser
effect, although still very noticeable. Presently the only choice
is to run with no EMS manager, just HIMEM.SYS.
It may also help to link the program with BC4.OBJ.
-------------------------------------------------------------------
24. R6001 ERROR NOT DETECTED WITH /NULL SWITCH
-------------------------------------------------------------------
Problem: BOUNDS-CHECKER does not detect an overwrite to the
Copyright block of the Data Segment (Run Time Error R6001 - null
pointer assignment) when the /NULL switch has been selected.
Solution: The size of the Copyright block varies depending on
the compiler and its version. BOUNDS-CHECKER uses a value of 40H as
the size of this block, but in some cases the block may be larger.
You can determine the size of this block from the .MAP file. For
Microsoft programs, use the size of the module named "NULL" in the
first section of the .MAP file. For Borland programs, use the size
of the procedure named "DATASEG@" within the "Publics by Value"
section. The example below shows how to patch BCHK.EXE to increase
the size protected by BOUNDS-CHECKER to 45H:
ren bchk.exe bchk.bin
debug bchk.bin
-r (get contents of CS register)
-s CS+1000:0 lffff bf 40 00
(prints an address in xxxx:yyyy format)
-e address+1 45 (Change the 40 to 45)
-w
-q
ren bchk.bin bchk.exe
NOTE: If BOUNDS-CHECKER is being run with Soft-ICE installed, a
similar patch must be made to Soft-ICE, because when Soft-ICE is
installed, BOUNDS-CHECKER uses the Soft-ICE routines. The location
is within the first 64K of Soft-ICE, so the patch sequence will be
as follows:
ren s-ice.exe s-ice.bin
debug s-ice.bin
-s 0:0 lffff bf 40 00
(prints an address in xxxx:yyyy format)
-e address+1 45 (Change the 40 to 45)
-w
-q
ren s-ice.bin s-ice.exe
-------------------------------------------------------------------
25. ACCESSES TO INTERRUPT VECTOR TABLE
-------------------------------------------------------------------
Problem: Program runs without BOUNDS-CHECKER but pops up with
an access to the Interrupt Vector Table when running with it.
Solution: BOUNDS-CHECKER zeroes the stack so that it can
determine how much was used - this may set some stack variables to
zero. Try using the /NZS switch when running BOUNDS-CHECKER.
-------------------------------------------------------------------
26. FLOATING POINT NUMBERS CAUSE "CODE OVERWRITE" MESSAGE
-------------------------------------------------------------------
Problem: When working with floating point numbers BOUNDS-CHECKER
keeps popping up with "CODE OVERWRITE" messages.
Solution: Floating point numbers will always overwrite the code
area. SMART MODE will catch this. Run with /SMART switch on.
-------------------------------------------------------------------
27. USING FarMalloc OR FarFree AS LIBRARY NAMES (MICROSOFT)
-------------------------------------------------------------------
Problem: BOUNDS-CHECKER does not distinguish between capital and
lower case letters, so if you use the name FarMalloc or FarFree for
one of your own routines, it will treat them like the Borland
libraries "farmalloc" and "farfree". It will trap on those routines
and attempt to process them, which could cause it to blow up.
Solution: Edit the ROUTINE.DAT file to put a semicolon as the
first character on any line where the name might be confused with
the name of one of your routines. This makes it a comment so that
BOUNDS-CHECKER does not process that name. For example, if your
program uses FarMalloc, comment out the line for the Borland
_farmalloc routine.
-------------------------------------------------------------------
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -