dos4gwqa.gml

开放源码的编译器open watcom 1.6.0版的源代码

.ix '&dos4gprd' 'VM configuration'
.np
Here are some recommendations for setting up the &dos4gprd virtual
memory manager.
.begnote
.note VIRTUALSIZE
.ix 'DOS4GVM' 'VIRTUALSIZE'
.ix 'VIRTUALSIZE virtual memory option'
Set to no more than twice the total amount of memory (virtual and
otherwise) your program requires. If your program has 16 MB of code
and data, set to 32 MB. (There is only a small penalty for setting
this value larger than you will need, but your program won't run if
you set it too low.) See (7d) above.
.note MINMEM
.ix 'DOS4GVM' 'MINMEM'
.ix 'MINMEM virtual memory option'
Set to the minimum hardware requirement for running your application.
(If you require a 2 MB machine, set to 2048).
.note MAXMEM
.ix 'DOS4GVM' 'MAXMEM'
.ix 'MAXMEM virtual memory option'
Set to the maximum amount of memory you want your application to use.
If you don't spawn any other applications, set this large (e.g.,
32000) to make sure you can use all available physical memory. If you
do spawn, see (7b) above.
.note SWAPMIN
.ix 'DOS4GVM' 'SWAPMIN'
.ix 'SWAPMIN virtual memory option'
Don't use this if you want the best possible VM performance. The
trade-off is that &dos4gprd will create a swap file as big as your
VIRTUALSIZE.
.note SWAPINC
.ix 'DOS4GVM' 'SWAPINC'
.ix 'SWAPINC virtual memory option'
Don't use this if you want the best possible VM performance.
.note DELETESWAP
.ix 'DOS4GVM' 'DELETESWAP'
.ix 'DELETESWAP virtual memory option'
&dos4gprd's VM will start up slightly slower if it has to create the
swap file afresh each time. However, unless your swap file is very
large, DELETESWAP is a reasonable choice; it may be required if you
spawn another &dos4gprd program at the same time. See (7b) above.
.endnote
.*
.endnote
.*
.section Debugging
.*
.begnote $setptnt 2
.*
.note 8a. Attempting to debug a bound application.
.*
.ix '&dos4gprd' 'debugging bound applications'
.np
You can't debug a bound application. The 4GWBIND utility (included
with &dos4gprd Professional) will allow you to take apart a bound
application so that you can debug it:
.millust begin
4GWBIND -U <boundapp.exe> <yourapp.exe>
.millust end
.*
.keep
.note 8b. Debugging with an old version of the &company debugger.
.*
.ix '&dos4gprd' 'debugger version'
.np
&dos4gprd supports versions 8.5 and up of the &company C, C++ and
FORTRAN compilers. However, in order to debug your unbound application
with a &company debugger, you must have version 9.5a or later of the
debugger.
.np
.ix '&dos4gprd' '4GWPRO.EXE'
.ix '4GWPRO.EXE'
If you have an older version of the debugger, we strongly recommend
that you contact &company to upgrade your compiler and tools. The only
way to debug a &dos4gprd Professional application with an old version
of the debugger is to rename 4GWPRO.EXE to DOS4GW.EXE and make sure
that it's either in the current directory or the first DOS4GW.EXE on
the DOS PATH.
.np
Tenberry will not provide technical support for this configuration;
it's up to you to keep track of which DOS extender is which.
.*
.keep
.note 8c. Meaning of "unexpected interrupt" message/error 2001.
.*
.ix '&dos4gprd' 'unexpected interrupt'
.np
In version 1.95 of &dos4gprd, we revised the "unexpected interrupt"
message to make it easier to understand.
.np
For example, the message:
.code begin
Unexpected interrupt 0E (code 0) at 168:10421034
.code end
.pc
is now printed:
.code begin
error (2001): exception 0Eh (page fault) at 168:10421034
.code end
.pc
followed by a register dump, as before.
.np
This message indicates that the processor detected some form of
programming error and signaled an exception, which &dos4gprd trapped
and reported. Exceptions which can be trapped include:
.millust begin
00h     divide by zero
01h     debug exception OR null pointer used
03h     breakpoint
04h     overflow
05h     bounds
06h     invalid opcode
07h     device not available
08h     double fault
09h     overrun
0Ah     invalid TSS
0Bh     segment not present
0Ch     stack fault
0Dh     general protection fault
0Eh     page fault
.millust end
.np
When you receive this message, this is the recommended course of
action:
.autonote
.note
Record all of the information from the register dump.
.note
Determine the circumstances under which your program fails.
.note
Consult your debugger manual, or an Intel 386, 486 or Pentium
Programmer's Reference Manual, to determine the circumstances under
which the processor will generate the reported exception.
.note
Get the program to fail under your debugger, which should stop the
program as soon as the exception occurs.
.note
Determine from the exception context why the processor generated an
exception in this particular instance.
.endnote
.*
.keep
.note 8d. Meaning of "transfer stack overflow" message/error 2002.
.*
.ix '&dos4gprd' 'transfer stack overflow'
.np
In version 1.95 of &dos4gprd, we added more information to the
"transfer stack overflow" message. The message (which is now followed
by a register dump) is printed:
.code begin
error (2002): transfer stack overflow
on interrupt <number> at <address>
.code end
.np
This message means &dos4gprd detected an overflow on its interrupt
handling stack. It usually indicates either a recursive fault, or a
hardware interrupt handler that can't keep up with the rate at which
interrupts are occurring. The best way to understand the problem is to
use the VERBOSE option in &dos4gprd to dump the interrupt history on
the transfer stack; see (8e) below.
.*
.keep
.note 8e. Making the most of a &dos4gprd register dump.
.*
.ix '&dos4gprd' 'register dump'
.ix 'DOS4G' 'VERBOSE option'
.np
If you can't understand your problem by running it under a debugger,
the &dos4gprd register dump is your best debugging tool. To maximize
the information available for postmortem debugging, set the
environment variable DOS4G to VERBOSE, then reproduce the crash and
record the output.
.np
Here's a typical register dump with VERBOSE turned on, with
annotations.
.in -0.3i
.code begin
1 &dos4gprd error (2001): exception 0Eh (page fault)
                                              at 170:0042C1B2
2 TSF32: prev_tsf32 67D8
3 SS       178 DS       178 ES       178 FS         0 GS        20
  EAX 1F000000 EBX        0 ECX   43201C EDX        E
  ESI        E EDI        0 EBP   431410 ESP   4313FC
  CS:IP  170:0042C1B2 ID 0E COD        0 FLG    10246
4 CS=  170, USE32, page granular, limit FFFFFFFF, base        0, acc CF9B
  SS=  178, USE32, page granular, limit FFFFFFFF, base        0, acc CF93
  DS=  178, USE32, page granular, limit FFFFFFFF, base        0, acc CF93
  ES=  178, USE32, page granular, limit FFFFFFFF, base        0, acc CF93
  FS=    0, USE16, byte granular, limit        0, base       15, acc  0
  GS=   20, USE16, byte granular, limit     FFFF, base     6AA0, acc 93
5 CR0: PG:1 ET:1 TS:0 EM:0 MP:0 PE:1   CR2: 1F000000 CR3: 9067
6 Crash address (unrelocated) = 1:000001B2
7 Opcode stream: 8A 18 31 D2 88 DA EB 0E 50 68 39 00 43 00 E8 1D
  Stack:
8 0178:004313FC 000E 0000 0000 0000 C2D5 0042 C057 0042 0170 0000 0000 0000
  0178:00431414 0450 0043 0452 0043 0000 0000 1430 0043 CBEF 0042 011C 0000
  0178:0043142C C568 0042 0000 0000 0000 0000 0000 0000 F248 0042 F5F8 0042
  0178:00431444 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
  0178:0043145C 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
  0178:00431474 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
9 Last 4 ints: 21 @ 170:42CF48/21 @ 170:42CF48/21 @ 170:42CF48/E @ 170:42C1B2/
.code end
.in +0.3i
.autonote
.note
The error message includes a synopsis of the problem. In this case,
the processor signaled a page fault exception while executing at
address 170:0042C1B2.
.note
The prev_tsf32 field is not usually of interest.
.note
These are the register values at the time of the exception. The
interrupt number and error code (pushed on the stack by the processor
for certain exceptions) are also printed.
.note
The descriptors referenced by each segment register are described for
your convenience. USE32 segments in general belong to your program;
USE16 segments generally belong to the DOS extender. Here, CS points
to your program's code segment, and SS, DS, and ES point to your data
segment. FS is NULL and GS points to a DOS extender segment.
.note
The control register information is not of any general interest,
except on a page fault, when CR2 contains the address value that
caused the fault. Since EAX in this case contains the same value, an
attempt to dereference EAX could have caused this particular fault.
.note
If the crash address (unrelocated) appears, it tells you where the
crash occurred relative to your program's link map. You can therefore
tell where a crash occurred even if you can't reproduce the crash in a
debugger.
.note
The opcode stream, if it appears, shows the next 16 bytes from the
code segment at the point of the exception. If you disassemble these
instructions, you can tell what instructions caused the crash, even
without using a debugger. In this case, 8A 18 is the instruction
.mono mov bl,[eax].
.note
72 words from the top of the stack, at the point of the exception, may
be listed next. You may be able to recognize function calls or data
from your program on the stack.
.note
The four interrupts least to most recently handled by &dos4gprd in
protected mode are listed next. In this example, the last interrupt
issued before the page fault occurred was an INT 21h (DOS call) at
address 170:42CF48. Sometimes, this information provides helpful
context.
.endnote
.np
Here's an abridged register dump from a stack overflow.
.in -0.3i
.code begin
  &dos4gprd error (2002): transfer stack overflow
                                  on interrupt 70h at 170:0042C002
  TSF32: prev_tsf32 48C8
  SS        C8 DS       170 ES        28 FS         0 GS        20
  EAX AAAAAAAA EBX BBBBBBBB ECX CCCCCCCC EDX DDDDDDDD
  ESI 51515151 EDI D1D1D1D1 EBP B1B1B1B1 ESP     4884
1 CS:IP  170:0042C002 ID 70 COD        0 FLG        2
  ...
2 Previous TSF:
  TSF32: prev_tsf32 498C
  SS        C8 DS       170 ES        28 FS         0 GS        20
  EAX AAAAAAAA EBX BBBBBBBB ECX CCCCCCCC EDX DDDDDDDD
  ESI 51515151 EDI D1D1D1D1 EBP B1B1B1B1 ESP     4960
3 CS:IP  170:0042C002 ID 70 COD        0 FLG        2
  ...
  Previous TSF:
  TSF32: prev_tsf32 67E4
  SS       178 DS       170 ES        28 FS         0 GS        20
  EAX AAAAAAAA EBX BBBBBBBB ECX CCCCCCCC EDX DDDDDDDD
  ESI 51515151 EDI D1D1D1D1 EBP B1B1B1B1 ESP   42FFE0
4 CS:IP  170:0042C039 ID 70 COD        0 FLG      202
5 Opcode stream: CF 66 B8 62 25 66 8C CB 66 8E DB BA 00 C0 42 00
  Last 4 ints: 70 @ 170:42C002/70 @ 170:42C002/70 @ 170:42C002/70 @ 170:42C002/
.code end
.in +0.3i
.autonote
.note
We overflowed the transfer stack while trying to process an interrupt
70h at 170:0042C002.
.note
The entire interrupt history from the transfer stack is printed next.
The prev_tsf32 numbers increase as we progress from most recent to
least recent interrupt. All of these interrupts are still pending,
which is why we ran out of stack space.
.note
Before we overflowed the stack, we got the same interrupt at the same
address. For a recursive interrupt situation, this is typical.
.note
The oldest frame on the transfer stack shows the recursion was touched
off at a slightly different address. Looking at this address may help
you understand the recursion.
.note
The opcode stream and last four interrupt information comes from the
newest transfer stack frame, not the oldest.
.endnote
.*
.endnote
.*
.section Compatibility
.*
.begnote $setptnt 2
.*
.note 9a. Running &dos4gprd applications from inside Lotus 1-2-3.
.*
.ix '&dos4gprd' 'Lotus 1-2-3'
.ix 'Lotus 1-2-3'
.ix 'PRIVATXM'
.np
In order to run &dos4gprd applications while "shelled out" from Lotus
1-2-3, you must use the PRIVATXM program included with your &company
compiler. Otherwise, 1-2-3 will take all of the memory on your machine
and prevent &dos4gprd from using it.
.np
Before starting 1-2-3, you must set the DOS16M environment variable to
limit Lotus' memory use (see your &company manual). After shelling
out, you must run PRIVATXM, then clear the DOS16M environment variable
before running your application.
.*
.keep
.note 9b. EMM386.EXE provided with DOS 6.0.
.*
.ix '&dos4gprd' 'EMM386.EXE'
.ix 'EMM386.EXE'
.np
We know of at least three serious bugs in the EMM386.EXE distributed
with MS-DOS 6.0, one involving mis-counting the amount of available
memory, one involving mapping too little of the High Memory Area (HMA)
into its page tables, and one involving allocation of EMS memory.
Version 1.95 of &dos4gprd contains workarounds for some of these
problems.
.np
If you are having problems with &dos4gprd and you are using an
EMM386.EXE dated 3-10-93 at 6:00:00, or later, you may wish to try the
following workarounds, in sequence, until the problem goes away.
.begbull
.bull
Configure EMM386 with both the NOEMS and NOVCPI options.
.bull
Convert the DEVICEHIGH statements in your CONFIG.SYS to DEVICE
statements, and remove the LH (Load High) commands from your
AUTOEXEC.BAT.
.bull
Run in a Windows DOS box.
.bull
Replace EMM386 with another memory manager, such as QEMM-386, 386Max,
or an older version of EMM386.
.bull
Run with HIMEM.SYS alone.
.endbull
.np
You may also wish to contact Microsoft Corporation to inquire about
the availability of a fix.
.*
.keep
.note 9c. Spawning under OS/2 2.1.
.*
.ix '&dos4gprd' 'OS/2 bug'
.np
We know of a bug in OS/2 2.1 that prevents one &dos4gprd application
from spawning another over and over again. The actual number of
repeated spawns that are possible under OS/2 varies from machine to
machine, but is generally about 30.
.np
This bug also affects programs running under other DOS extenders, and
we have not yet found a workaround, other than linking your two
programs together as a single program.
.*
.keep
.note 9d. "DPMI host error: cannot lock stack".
.*
.ix '&dos4gprd' 'cannot lock stack'
.ix 'DPMI_MEMORY_LIMIT' 'DOS setting'
.np
This error message almost always indicates insufficient memory, rather
than a real incompatibility. If you see it under an OS/2 DOS box, you
probably need to edit your DOS Session settings and make
DPMI_MEMORY_LIMIT larger.
.*
.keep
.note 9e. Bug in Novell TCPIP driver.
.*
.ix '&dos4gprd' 'TCPIP.EXE'
.ix 'TCPIP.EXE'
.ix 'Novell' 'TCPIP.EXE'
.np
Some versions of a program from Novell called TCPIP.EXE, a real-mode
program, will cause the high words of EAX and EDX to be altered during
a hardware interrupt. This bug breaks protected-mode software (and
other real-mode software that uses the 80386 registers). Novell has
released a newer version of TCPIP that fixes the problem; contact
Novell to obtain the fix.
.*
.keep
.note 9f. Bugs in Windows NT.
.*
.ix '&dos4gprd' 'Windows NT bug'
.ix '&dos4gprd' 'DOSX.EXE'
.ix 'DOSX.EXE'
.np
The initial release of Windows NT includes a DPMI host, DOSX.EXE, with
several serious bugs, some of which apparently cannot be worked
around. We cannot warranty operation of &dos4gprd under Windows NT at
this time, but we are continuing to exercise our best efforts to work
around these problems.
.np
You may wish to contact Microsoft Corporation to inquire about the
availability of a new version of DOSX.EXE.
.endnote