home *** CD-ROM | disk | FTP | other *** search
/ Monster Media 1993 #2 / Image.iso / clipper / bl210dem.zip / READ.ME < prev   
Text File  |  1993-06-02  |  23KB  |  656 lines
  1. READ.ME                 BLINKER 2.1 Release notes               93/06/02
  2. -------                 -------------------------               --------
  3.  
  4.   This READ.ME contains IMPORTANT INFORMATION which is not available in
  5.   the manual. Please read this document before calling for technical
  6.   support. It describes last minute changes and additions to the BLINKER
  7.   manual and product made since the manual was printed. Where
  8.   differences occur, the information contained herein supersedes the
  9.   Norton Guide, which in turn supersedes the printed manual.
  10.  
  11.   You may find it worthwhile to print and study this file before using
  12.   the product. There is a completely updated Norton Guide file which
  13.   contains the new commands and functions, but we have repeated them
  14.   below for the benefit of those people who do not have a Norton Guide
  15.   Reader.
  16.  
  17.   If the installation program was unable to update to Blinker 2.1
  18.   automatically then the update program BLIUPD.EXE should be copied to
  19.   the Blinker 2.0x directory and run from the DOS prompt.
  20.   
  21. Contents
  22. --------
  23.   1. General Notes
  24.   2. Additional compiler information
  25.     2.1. Microsoft C/C++ / Visual C++
  26.     2.2. Visual BASIC for DOS
  27.     2.3. WATCOM C
  28.     2.4. Stony Brook Compilers
  29.     2.5. RM FORTRAN
  30.   3. Swap system
  31.     3.1. Keyboard stuffing
  32.     3.2. BLINKER environment settings
  33.     3.3. Other additions
  34.   4. New / changed link script commands
  35.   5. New link time error messages
  36.   6. Turbo Debugger support
  37.   7. Functions for other swappers
  38.  
  39.  
  40. 1. General Notes
  41. ----------------
  42.  
  43.   Subdirectories within the Blinker 2.1 installation directory contain
  44.   header files defining all the available Blinker run time functions for
  45.   each major language. Those functions defined as having optional
  46.   parameters should pass the value -1 as a dummy for those languages
  47.   which do not support optional function parameters.
  48.  
  49.   CodeView is only supported with external overlay files (created using
  50.   the SECTION INTO command). Error message 1117 is displayed if CodeView
  51.   is specified with internal overlays. Microsoft C/C++ 7.0, Visual C++
  52.   and Visual BASIC for DOS require version 5 of CodeView information, so
  53.   use the CVVERSION 5 command to specify this in the link script file.
  54.  
  55.   Japanese users should note that Blinker 2.1 will run on all machines
  56.   provided that the blinking eyes are disabled with the BLINKER MESSAGE
  57.   NOBLINK command. This may appear on the command line or anywhere in
  58.   the link script file.
  59.  
  60.   When linked with Blinker, Clipper's default STACK is increased to
  61.   5235, equivalent to a BLINKER PROCEDURE DEPTH OF 50.
  62.  
  63.   In many cases it should be possible to use incremental linking with
  64.   Clipper applications which previously required too much additional
  65.   memory, by linking with the CLS87MAX or CL501MAX script files to
  66.   overlay as much as possible, and then enabling the overlay caching.
  67.  
  68.   It should be noted that to use BASIC with Blinker the final program
  69.   must run as a separate EXE file, i.e. all modules must be compiled
  70.   with the /O option. When linking BASIC please compile the BASIC error
  71.   handler BAS\BLERRPRG.BAS for the appropriate string model (Near or
  72.   Far) and link it into the ROOT of the program.
  73.  
  74.   Three new functions BLIDEMDTEFOR (), BLIERRPRMFOR (), BLISERNUMFOR ()
  75.   have been added to support the Blinker functions which return strings
  76.   to FORCE.
  77.  
  78.   The startup module for Assembler programs must reside in the root of
  79.   the program.
  80.  
  81.  
  82. 2. Additional compiler information
  83. ----------------------------------
  84.  
  85. 2.1. Microsoft C/C++ / Visual C++
  86. ---------------------------------
  87.   These compilers are fully supported. When using CodeView with these
  88.   compilers please specify version 5 of CodeView information in the link
  89.   script file using the CVVERSION 5 command (in addition to the CODEVIEW
  90.   command).
  91.  
  92.   CodeView 4.1 seems to leave the EXE file open the first time it loads
  93.   it, so either link it READONLY, or just restart the program if you get
  94.   the open error.
  95.  
  96.  
  97. 2.2. Visual BASIC for DOS
  98. -------------------------
  99.   This compiler is fully supported. When using CodeView with this
  100.   compiler please specify version 5 of CodeView information in the link
  101.   script file using the CVVERSION 5 command (in addition to the CODEVIEW
  102.   command).
  103.  
  104.  
  105. 2.3. WATCOM C
  106. -------------
  107.   WatCom C requires an explicit DOSSEG command. It can appear anywhere
  108.   on the command line or in the link script file.
  109.  
  110.  
  111. 2.4. Stony Brook Compilers
  112. --------------------------
  113.   The compiler run time libraries, and any libraries produced by the
  114.   Stony Brook librarian must be SEARCHed. Use of the LIB command on
  115.   these libraries will result in an internal Blinker error 1191: invalid
  116.   library number. Alternatively, the libraries may be rebuilt using the
  117.   Microsoft librarian (LIB.EXE).
  118.  
  119.   When using overlays, the startup module must be in the root.
  120.  
  121.   2.4.1. Modula 2
  122.   ---------------
  123.   When using overlays, compile using the LARGE model:
  124.  
  125.   m2 myprog.mod /CODE:L
  126.  
  127.   2.4.2. Pascal+
  128.   --------------
  129.   When using overlays, compile using the LARGE model, and place
  130.   constants in a separate segment:
  131.  
  132.   ppc myprog.pas //CODE:L //CONSTANT:L
  133.  
  134.  
  135. 2.5. RM FORTRAN
  136. ---------------
  137.   RM FORTRAN is fully supported with Blinker 2.1.
  138.  
  139.  
  140. 3. Swap system
  141. --------------
  142. 3.1 Keyboard stuffing
  143. ---------------------
  144.  
  145. SWPKEYBRD() - Stuff keystrokes into the child program
  146. SWPKEYCLR() - Alter the number of 'key not ready' signals sent
  147.  
  148. SWPKEYBRD()
  149. -----------
  150.  
  151. Function:   SWPKEYBRD/SWPKEYBRDBAS (Basic)
  152. Syntax  :   nivalue = SWPKEYBRD(cString)
  153. Purpose :   Stuff keystrokes into the child application
  154. Return  :   An integer value:
  155.  
  156.             0 -> OK
  157.  
  158.            -1 -> open quote in string
  159.            -2 -> open { (extended key definition)
  160.  
  161.            +N -> parsing error at location N in input string.
  162.  
  163. The SWPKEYBRD function allows the parent program to stuff the keyboard
  164. with a series of keystrokes prior to executing the child program. Use of
  165. this function will allow you complete control over the execution of the
  166. child program.
  167.  
  168. SWPKEYBRD() should work with most programs that use the BIOS keyboard
  169. functions 0,1,10H and 11H to read keyboard input. Programs that access
  170. the keyboard hardware directly (such as MS Word) will not see stuffed
  171. keystrokes, and so cannot be controlled by this function.
  172.  
  173. The maximum number of keystrokes that can be stuffed is 250.
  174.  
  175. SWPKEYBRD Parameters
  176. --------------------
  177.  
  178. SWPKEYBRD takes a single string parameter made up of the following
  179. components:
  180.  
  181. a) embedded sub-strings within quotes
  182. b) shift/ctrl/alt key combinations and keys that cannot be
  183.    specified in ascii form, such as {pgup} and {enter}
  184.  
  185. You may separate strings and shifted key combinations with spaces.
  186.  
  187. eg:
  188.  
  189. x = SWPKEYBRD(" {tab} 'Testing...' {enter} {alt-f} 's' {alt-x} " )
  190.  
  191. Clearing the keyboard buffer
  192. ----------------------------
  193.  
  194. By default, SWPKEYBRD() fools the child program into thinking that the
  195. keyboard buffer has been cleared between each keystroke. This will make key
  196. stuffing operate more reliably with programs that clear the keyboard buffer on
  197. a regular basis. This behaviour can be changed using the function SWPKEYCLR()
  198. to disable this feature.
  199.  
  200. Embedded substrings
  201. -------------------
  202.  
  203. Embedded sub-strings will usually contain ASCII characters found on the
  204. keyboard, such as A-Z, a-z, 0-9, !@#$%^&*() and so on. These characters are
  205. translated by SWPKEYBRD() into the keycodes associated with the keys that bear
  206. the character legend on a _US_ keyboard.
  207.  
  208. It is possible for an embedded sub-string to contain characters that are not
  209. present on the keyboard, such as international characters, box and line
  210. characters. When SWPKEYBRD() encounters such a character, it generates a
  211. keystroke that is the equivalent {alt-nnn} keycode, where nnn is the ascii
  212. value of the character in question.
  213.  
  214. Quotes
  215. ------
  216.  
  217. Embedded substrings may start and end with either a single (') or a double (") 
  218. quote. This allows you to use either within the quoted text:
  219.  
  220. swpkeybrd("{enter}'Then he said "hello" and left'{enter}")
  221. swpkeybrd('{enter}"Please press 'X' now!"{enter}')
  222.  
  223. Note that most languages will use the first and last quote within the string 
  224. as delimiters. The string you pass to SWPKEYBRD() must be within _another_ set 
  225. of quotes.
  226.  
  227. Some languages may not allow the use of two different quotes (eg BASIC)
  228. - in this case the quotes may be passed using the CHR$(n) function or
  229. equivalent:
  230.  
  231. swpkeybrd("{enter}'Then he said "+CHR$(34)+"hello"+CHR$(34)+" and left'{enter}")
  232.  
  233.  
  234. Extended Key combinations
  235. -------------------------
  236.  
  237. In addition to quoted text, SWPKEYBRD() can also pass other keystrokes that 
  238. cannot be represented properly by normal ASCII characters. Many of these 
  239. keystrokes may be used in conjunction with a shift state. The three available 
  240. shift states are:
  241.  
  242. shift
  243. ctrl
  244. alt
  245.  
  246. When a shift state key is specified, it should be precede the actual key 
  247. definition, and be separated from it by a '-' character - eg:
  248.  
  249. {shift-f7}{ctrl-a}{alt-esc}
  250.  
  251. You cannot use more than one shift state at a time - the BIOS does not support 
  252. this. If the child program uses multiple shift states simultaneously, such as 
  253. {ctrl}+{alt}, {ctrl}+{shift}, you will not be able to control it using 
  254. SWPKEYBRD(), as it either directly accesses the keyboard hardware, or it uses 
  255. shift state information in the BIOS data area, which SWPKEYBRD() does not 
  256. attempt to emulate.
  257.  
  258. The following keys are available:
  259.  
  260. {f1}-{f12}
  261. {shift-f1} - {shift-f12}
  262. {ctrl-f1} - {ctrl-f12}
  263. {alt-f1} - {alt-f12}
  264.  
  265. {ctrl-a} - {ctrl-z}
  266. {alt-a} - {alt-z}
  267. {ctrl-0} - {ctrl-9}
  268.  
  269. {esc} {tab} {bksp} {enter}
  270. {space} {ins} {del}
  271.  
  272. {ctrl-esc} {ctrl-tab} {ctrl-bksp} {ctrl-enter}
  273. {ctrl-space} {ctrl-ins} {ctrl-del}
  274.  
  275. {ctrl-prtscr}
  276.  
  277. note that {ctrl-prtscr} is the only flavor of print screen that the bios 
  278. passes through, and so is the only one that can be stuffed.
  279.  
  280. {alt-esc} {alt-tab} {alt-bksp} {alt-enter}
  281. {alt-space} {alt-ins} {alt-del}
  282.  
  283.  
  284. Numeric Keypad Cursor Control Keys
  285. ----------------------------------
  286.  
  287. Please note these keys are found on the numeric keypad.
  288.  
  289. {up} {down} {left} {right}
  290. {home} {end} {pgup} {pgdn}
  291.  
  292. {ctrl-up} {ctrl-down} {ctrl-left} {ctrl-right}
  293. {ctrl-home} {ctrl-end} {ctrl-pgup} {ctrl-pgdn}
  294.  
  295. {alt-up} {alt-down} {alt-left} {alt-right}
  296. {alt-home} {alt-end} {alt-pgup} {alt-pgdn}
  297.  
  298. Extended Cursor Control Keys
  299. ----------------------------
  300.  
  301. These keys correspond to the separate gray keys found on 101/102 key extended 
  302. keyboards. The * character indicates these gray keys:
  303.  
  304. {*ins} {*del} {*end} {*pgup} {*pgdn} {*home}
  305. {*up} {*down} {*right} {*left}
  306.  
  307. {ctrl-*ins} {ctrl-*del} {ctrl-*end} {ctrl-*pgup} {ctrl-*pgdn}
  308. {ctrl-*home} {ctrl-*up} {ctrl-*down} {ctrl-*right} {ctrl-*left}
  309.  
  310. {alt-*ins} {alt-*del} {alt-*end} {alt-*pgup} {alt-*pgdn}
  311. {alt-*home} {alt-*up} {alt-*down} {alt-*right} {alt-*left}
  312.  
  313. Numeric Keypad Keys
  314. -------------------
  315.  
  316. Normally, when you specify a number (0-9) as part of an embedded string, the 
  317. keystroke generated will be from the numeric keys along the top of the 
  318. keyboard. If you require to stuff keystrokes from the numeric pad, use the 
  319. following (the # indicates the keystroke is from the numeric pad):
  320.  
  321. {#0} {#1} {#2} {#3} {#4} {#5}
  322. {#6} {#7} {#8} {#9} {#.}
  323. {#/} {#*} {#-} {#+} {#enter}
  324.  
  325. {ctrl-#0} {ctrl-#1} {ctrl-#2} {ctrl-#3} {ctrl-#4} {ctrl-#5}
  326. {ctrl-#6} {ctrl-#7} {ctrl-#8} {ctrl-#9} {ctrl-#.}
  327. {ctrl-#/} {ctrl-#*} {ctrl-#-} {ctrl-#+} {ctrl-#enter}
  328.  
  329. {alt-#0} {alt-#1} {alt-#2} {alt-#3} {alt-#4} {alt-#5}
  330. {alt-#6} {alt-#7} {alt-#8} {alt-#9} {alt-#.}
  331. {alt-#/} {alt-#*} {alt-#-} {alt-#+} {alt-#enter}
  332.  
  333. International Keyboard Drivers
  334. ------------------------------
  335.  
  336. Keystrokes supplied to the child process are passed directly from the swap 
  337. kernel, by-passing any international keyboard driver that may be loaded. This 
  338. has the effect of making the keys appear to have come from a US keyboard. The 
  339. international keyboard handler will regain control, as normal, as soon as 
  340. SWPKEYBRD() has stuffed all its keystrokes.
  341.  
  342. SWPKEYCLR
  343. ---------
  344.  
  345.   Function : Alter frequency of keyboard buffer clearing
  346.  
  347.   Syntax   : niValue = SWPKEYCLR(niValue)
  348.  
  349.   Return   : The previous setting
  350.  
  351.   Default  : 3
  352.  
  353.   This function can be used to alter the number of times the swap
  354.   function indicates to the child process that the keyboard buffer is
  355.   empty between keystrokes. Increasing the number of clear signals sent
  356.   to the child may help in situations where the child loses keystrokes.
  357.   Normally this function will not be required, as the default will work
  358.   with most programs.
  359.  
  360.   Example:
  361.  
  362.   SWPKEYCLR(5)               // five clears between each stuffed key
  363.  
  364. 3.2. BLINKER environment settings
  365. ---------------------------------
  366.   The swap system now examines the BLINKER (or whatever it is renamed
  367.   to) environment variable for the following settings. These settings
  368.   OVERRIDE the SWPxxxxxx() functions which are set during program
  369.   execution.
  370.  
  371.         /S3n (n=0 or 1) Enable / disable use of EMS 3.2 only
  372.         /SEn (n=0 or 1) Enable / disable use of EMS
  373.         /SPn (n=0 or 1) Enable / disable save of EMS Pframe
  374.         /SUn (n=0 or 1) Enable / disable use of UMBs
  375.         /SXn (n=0 or 1) Enable / disable use of XMS
  376.         /SDxxxx         Directory path for temporary files
  377.  
  378.   Note: If the directory path is also set with the SWAP environment
  379.   variable then it will override the BLINKER /SD setting.
  380.  
  381.  
  382. 3.3. Other additions
  383. --------------------
  384.  
  385. There are a few additional swap system functions which are not mentioned
  386. in the manual. For further examples of these functions see the SWAPDEMO
  387. program in the appropriate language subdirectory of the Blinker
  388. directory.
  389.  
  390. SWPADDSTR() - Add to the string set in the parent program
  391. SWPEMS320() - Limit the swapper to using EMS 3.2 calls
  392. SWPGETSTR() - Return the string stuffed by the child program
  393. SWPSETSTR() - Return a string to the parent program
  394.  
  395.  
  396. SWPADDSTR()
  397. -----------
  398.  
  399. Function:   SWPADDSTR/SWPADDSTRBAS (Basic)
  400. Syntax  :   nivalue = SWPADDSTR(cPID, cString)
  401. Purpose :   Add to a string returned to a previous parent program
  402. Return  :   A logical value
  403. See Also:   SWPSETSTR(), SWPGETSTR(), SWPSETPID(), SWPGETPID()
  404.  
  405. SWPADDSTR() is very similar to SWPSETSTR(), except that instead of returning a
  406. string to the named parent program, it appends to the string already set in
  407. the parent. In the case that no string has been returned to the parent,
  408. SWPADDSTR() operates identically to SWPSETSTR().
  409.  
  410. example:
  411.  
  412. success := SWPSETSTR("TEST","ONE")
  413. success := SWPADDSTR("TEST","TWO")
  414.  
  415. returns the string "ONETWO" to the program that has set a program ID of
  416. "TEST"
  417.  
  418. The return value is a logical indicating success or failure. There are three
  419. possible reasons for failure:
  420.  
  421. 1 - the named parent program is not currently in memory
  422. 2 - appending to the existing string would cause the total length to exceed
  423.     127 bytes.
  424. 3 - the parent was linked with a version of Blinker prior to 2.10
  425.  
  426.  
  427. SWPEMS320()
  428. -----------
  429.  
  430.   Function:     Limit the swapper to using EMS 3.2 calls
  431.  
  432.   Syntax :      lValue = SWPEMS320(lvalue)
  433.  
  434.   Return:       The previous setting
  435.  
  436.   Some offbeat/OEM EMS emulators have been giving some problems with the
  437.   swapper's use of EMS 4.0 level functions that appear to be improperly
  438.   implemented in the affected drivers. This function can be used to
  439.   force the swapper to only use EMS 3.2 functions.
  440.  
  441.   example:
  442.  
  443.   SWPEMS320(.T.)    // use only EMS 3.2 calls.
  444.  
  445.   This function will not be needed in most cases.
  446.  
  447.  
  448. SWPGETSTR()
  449. -----------
  450.  
  451. Function:   SWPGETSTR/SWPGETSTRBAS (Basic)
  452. Syntax  :   cstring = SWPGETSTR()
  453. Purpose :   Retrieve a string returned by a child program
  454. Return  :   A string
  455. See Also:   SWPSETSTR(), SWPADDSTR(), SWPSETPID()
  456.  
  457. SWPGETSTR() is used within the parent program to retrieve the string set by a
  458. child program.
  459.  
  460. * Parent program
  461. SWPSETPID("PARENT")
  462. SWPRUNCMD("child",0,"","")
  463. string = SWPGETSTR()
  464. ? "The string returned is : ",string // 'Hello'
  465. * eof parent
  466.  
  467. * Child program
  468. if SWPGETPID("PARENT")
  469.    SWPSETSTR("PARENT","Hello")
  470. endif
  471. quit
  472. * eof child
  473.  
  474.  
  475. SWPSETSTR()
  476. -----------
  477.  
  478. Function:   SWPSETSTR/SWPSETSTRBAS (Basic)
  479. Syntax  :   nivalue = SWPSETSTR(cPID, cString)
  480. Purpose :   Return a string to a previous parent program
  481. Return  :   An logical value
  482. See Also:   SWPADDSTR(), SWPGETSTR(), SWPSETPID(), SWPGETPID()
  483.  
  484. SWPSETSTR() can be used to return a string of up to 127 bytes from the child
  485. program to a parent. The string to be returned may not contain any NULLs,
  486. - the first NULL will be interpreted as a string terminator.
  487.  
  488. The parent to receive the string is identified using the program ID of the
  489. parent program (set in the parent using SWPSETPID()). The string may be
  490. retrieved by the parent program using SWPGETSTR().
  491.  
  492. example:
  493.  
  494. success := SWPSETSTR("TEST","OK")
  495.  
  496. returns the string "OK" to the program that has set a program ID of "TEST".
  497.  
  498. The return value is a logical indicating success or failure. There are three
  499. possible reasons for failure:
  500.  
  501. 1 - the named parent program kernel is not currently in memory
  502. 2 - the string to be returned is longer than 127 bytes
  503. 3 - the parent was linked with a version of Blinker prior to 2.10
  504.  
  505.  
  506. 4. New / changed link script commands
  507. -------------------------------------
  508.  
  509. // is now treated as a comment inside a link script file, so anything
  510.   following these characters is ignored. E.g.
  511.  
  512.   //      This is a link file
  513.   fi test        // first OBJ
  514.  
  515.  
  516. BLINKER EXECUTABLE NOBLINK
  517.  
  518.   Purpose : Causes NO Blinker code whatsoever to be linked in
  519.  
  520.   Syntax  : BLINKER EXECUTABLE NOBLINK
  521.  
  522.   Default : Disabled
  523.  
  524.   This command causes Blinker to ignore all overlays, demo restrictions,
  525.   and the Clipper 5.x paging system, and will give unresolved externals
  526.   for all Blinker functions. This is mainly used in order to create
  527.   small C / ASM programs with no overhead. DON'T USE FOR CLIPPER EXCEPT
  528.   FOR SMALL PROGRAMS WITHOUT OVERLAYS !!
  529.  
  530.  
  531. BLINKER MEMORY CLEAR
  532.  
  533.   Purpose : Clears all memory beyond the EXE file to a specified value
  534.  
  535.   Syntax  : BLINKER MEMORY CLEAR nnn
  536.  
  537.   Default : Disabled
  538.  
  539.   This command causes Blinker to clear all of memory above the
  540.   stack through to the top of memory with the decimal value specified (0
  541.   - 255). This can be used to help identify problems with uninitialised
  542.   memory etc., and programs should not normally be shipped with this
  543.   option enabled.
  544.  
  545.  
  546. DOSSEG
  547.  
  548.   Purpose : Use Microsoft DOS segment ordering
  549.   
  550.   Syntax  : DOSSEG
  551.  
  552.   Default : Disabled
  553.  
  554.   This command is used to specify that Blinker should arrange the
  555.   segments making up the program in conformance with the segment
  556.   ordering scheme used by the Microsoft high level language compilers.
  557.   Most compilers which require this segment ordering include a DOSSEG
  558.   request in each .OBJ created or in the language library, so this
  559.   command is not needed under normal circumstances.
  560.  
  561.   WatCom C requires an explicit DOSSEG command.
  562.  
  563.  
  564. EXTRAMEM
  565.  
  566.   Purpose : Limit the amount of extra memory allocated to a program by DOS
  567.  
  568.   Syntax  : EXTRAMEM nnnn
  569.  
  570.   Default : 1 MB
  571.  
  572.   This command is used to limit the amount of extra memory DOS will
  573.   allocate to a program. The parameter is the size, as a decimal number
  574.   of paragraphs BEYOND THE INITIALISED EXE SIZE, of the largest memory
  575.   block into which DOS will load the program. This is equivalent to the
  576.   /CPARM option of MSLink.
  577.   This command is used, amongst other things, to reduce the size of the
  578.   near heap in Medium and Large model programs.
  579.  
  580.  
  581. MEMORY
  582.  
  583.   Purpose : Set the size of the largest memory block allocated to a
  584.             program by DOS
  585.  
  586.   Syntax  : MEMORY nnnn
  587.  
  588.   Default : 1 MB
  589.  
  590.   This command is used to set the size, as a decimal number of
  591.   paragraphs, of the largest memory block into which DOS will load
  592.   the program.
  593.  
  594.  
  595. MURPHY
  596.  
  597.   The MURPHY command causes all overlays to be run at the same address
  598.   in memory, but does NOT yet fill the rest of the overlay area with INT
  599.   3 instructions.
  600.  
  601.  
  602. 5. New Link Time Error Messages
  603. -------------------------------
  604.  
  605. 1117: use of debugging information requires external overlays
  606.  
  607.   This release of Blinker supports the use of CodeView debugging
  608.   information in overlaid programs which use EXTERNAL OVERLAYS only.
  609.   Please refer to the manual on how to use the SECTION INTO command to
  610.   specify external overlay file(s). This is only necessary whilst
  611.   debugging with CodeView information.
  612.  
  613.  
  614. 6. Turbo Debugger support
  615. -------------------------
  616.  
  617.   Limited support consists of module source code with line
  618.      numbers, public data symbols and non-overlaid public code
  619.      symbols. We do not currently support overlaid code under
  620.      the Turbo Debugger, but plan to in a subsequent release.
  621.   TDCONVRT handles non-overlaid programs fine.
  622.   If a program contains C or ASM overlays then the -c option
  623.      must be used to create an external .TDS file, otherwise a
  624.      Blinker 1203 error will occur at run time. This is
  625.      because TDCONVRT places the debugging information
  626.      directly after the root of the .EXE file. It also creates
  627.      unusually large .TDS files with overlaid programs due to
  628.      some internal confusion, but they appear to function
  629.      correctly for the root part of the program.
  630.   Overlaid programs will otherwise run correctly, but
  631.      breakpoints on overlaid code will be ignored and display
  632.      meaningless code at the symbol addresses.
  633.   Turbo Debugger does not currently recognise the _main symbol
  634.      as output from Blinker and TDCONVRT, so when running a
  635.      program under the debugger select GOTO (Ctl G) and enter
  636.      "main" to locate the start of the program.
  637.  
  638. 7. Functions for other swappers
  639. -------------------------------
  640.  
  641.   Overlay () and Dr Switch work fine, but with other swappers it is
  642.   necessary to unhook the overlay manager before the swap and to rehook
  643.   it afterwards. 2.1 now has 2 functions BLIUNHOOK and BLIREINIT (with
  644.   preceding underscores for ASM etc.) which perform this function
  645.   (no parameters).
  646.  
  647.       e.g.                          or
  648.           BLIUNHOOK ();                    BLIUNHOOK ()
  649.           SWAP (....);                     HOLDEVCL (....)
  650.           BLIREINIT ();                    BLIREINIT ()
  651.  
  652.   Please note that these calls are *NOT* required when using the built
  653.   in swap function, SWPRUNCMD().
  654.  
  655. <eof>
  656.