🚀 go-pugleaf

Archive-name: msdos-programmer-faq/diff2
Last-modified: 21 July 1992


Please see part 1 for explanations.


- 12>Last-modified: 25 June 1992
+ 12>Last-modified: 19 July 1992

+ 19>            Copyright (C) 1992  Stan Brown, Oak Road Systems

-163>    - large and compact models (data pointers far):  DGROUP holds all
-164>      globals and static variables including string literals.
-166>    - huge model in Microsoft (data pointers far): same as large model.
+164>    - large, compact, and huge models in Microsoft (data pointers far):
+165>      DGROUP holds only initialized globals and static variables
+166>      including string literals, plus the stack and the near heap.
+168>    - large and compact models in Borland (data pointers far): DGROUP
+169>      holds initialized and uninitialized globals and static variables
+170>      including string literals, but not the stack or heap.

-181>Q202. How do I fix "stack plus data exceed 64K"?
-183>    This message is a variation of "DGROUP > 64K".  For causes, please
-184>    see the preceding Q.
+185>Q202. How do I fix "automatic data segment exceeds 64K" or "stack plus
+186>      data exceed 64K"?
+188>    These messages are a variation of "DGROUP > 64K".  For causes,
+189>    please see the preceding Q.

-189>    you can do.
+194>    you can do.  (This error can't occur in Borland's huge model.)

-206>    but it "sets aside [the 64K] limit," according to the BC++ 2.0
-207>    Programmer's Guide.  [...]
+211>    but "sets aside [the 64K] limit" and has no DGROUP group, according
+212>    to the BC++ 2.0 Programmer's Guide.  [...]

-217>    The problem is that each compiler uses calls to undocumented
+223>    One problem is that each compiler uses calls to undocumented

+232>    Another problem is that Borland's compact, large, and huge models
+233>    don't assume DS=SS, but Microsoft's do.  The -Fs option on the
+234>    Borland compiler, or one of the /A options on Microsoft, should take
+235>    care of this problem.

-226>    A vendor can [...]
+237>    A third-party vendor of compiled object libraries can [...]

-339>    Ctrl-Break.
+351>    Ctrl-Break.  However, if your program uses normal DOS input, the
+352>    characters ^C will appear on the screen when the user presses Ctrl-C
+353>    or Ctrl-Break.  There are many ways to work around that, including:
+354>    use INT 21 function 7, which allows redirection but doesn't display
+355>    the ^C (or echo any other character, for that matter); or use INT 16
+356>    function 0 or 10; or call _bios_keybrd( ) in MSC or bioskey( ) in
+357>    BC++; or hook INT 9 to discard Ctrl-C and Ctrl-Break before the
+358>    regular BIOS keyboard handler sees them; etc., etc.
+360>    You should be aware that Ctrl-C and Ctrl-Break are processed quite
+361>    differently internally.  Ctrl-Break, like all keystrokes, is
+362>    processed by the BIOS code at INT 9 as soon as the user presses the
+363>    keys, even if earlier keys are still in the keyboard buffer:  by
+364>    default the handler at INT 1B is called.  Ctrl-C is not special to
+365>    the BIOS, nor is it special to DOS functions 6 and 7; it _is_
+366>    special to DOS functions 1 and 8 when at the head of the keyboard
+367>    buffer.  You will need to make sure BREAK is OFF to prevent DOS
+368>    polling the keyboard for Ctrl-C during non-keyboard operations.

-- 
Stan Brown, Oak Road Systems                      brown@Ncoast.ORG