OnLine's Electronic Magazine (EMAG) Issue #10 The tenth issue of OnLine's Electronic Magazine (EMAG) is available for downloading in the Software Library. The file is EMAG10.ARC. Microsoft has created this magazine to provide our OnLine customers with information about the OnLine service, including techniques on how to most effectively use the service. We also hope the magazine will encourage you to send us feedback so that we can provide the best possible service to you, our OnLine customers. Table of Contents ----------------- Word 5.50 Introduction.......................................EMAG10-1 Converting Word 5.00 Macros for Use in Word 5.50.............EMAG10-2 Word Version 5.50 Articles..............by Microsoft OnLine Personnel (The information in these articles may also be found in the Knowledge Base by searching on the appropriate Q number shown in parentheses). Word 5.50: Viewing List Box Contents Without a Mouse (Word, Q67191)............................................EMAG10-3 Word 5.50: Installing Mouse Driver and Updating System (Word, Q66066)............................................EMAG10-4 Word 5.50: New Command-Line Switches (Word, Q66133)............................................EMAG10-5 Word 5.50 Freeing Up Memory When Shelling Out (Word, Q66065)............................................EMAG10-6 Word 5.50: Setup Does Not Overwrite Word Version 4.00 (Word, Q67157)............................................EMAG10-7 Decompressing Word 5.50 Files with Setup (Word, Q64464)............................................EMAG10-8 WORD.PIF Settings for Windows 3.00 (Word, Q65737)............................................EMAG10-9 What's New.............................by Microsoft Support Personnel (The information in these articles may also be found in the Knowledge Base by searching on the appropriate Q number shown in parentheses). Accessing Program Segment Prefix in OS/2 Bound Program (OS/2 SDK, Q66821).......................................EMAG10-10 COM/Serial Port Detection in OS/2 (OS/2 SDK, Q66236).......................................EMAG10-11 PM: Determining Which Button Is the Default or Focused Button (Presentation Manager, Q65966)...........................EMAG10-12 Adding and Removing FCF_SIZEBORDER Style of a PM Frame Window (Presentation Manager, Q66464)...........................EMAG10-13 Memory Requirements for Real-Mode CodeView (CV.EXE) (CodeView, Q66513).......................................EMAG10-14 How to Add Other Language Compilers to PWB's Build Options (PWB, Q65568)............................................EMAG10-15 What Happens to Stack Memory When Thread Terminates? (C Compiler, Q66295).....................................EMAG10-16 Using _psp for Pointer Checking (C Compiler, Q66127).....................................EMAG10-17 Differences/Enhancements from BASIC PDS 7.00 to 7.10 (BASIC Compiler, Q65598).................................EMAG10-18 How SUB and FUNCTION Windows Inherit DEFtype in QB.EXE Editor (QuickBASIC, Q47491).....................................EMAG10-19 Description of Stub Files and How They May Enlarge EXE (BASIC Compiler, Q62908).................................EMAG10-20 Which BASIC Versions Can CALL C, FORTRAN, Pascal, MASM (QuickBASIC, Q35965).....................................EMAG10-21 ====================================================================== EMAG10-1 Word 5.50 Introduction By Donna Inchinose This new version of Microsoft Word has been designed with two major goals in mind -- making the product easy to learn, as well as easy to use. To accomplish these goals, Microsoft has changed the interface, or the way Word looks, to a character window (CW) interface. The advantages of this new interface are: 1. A new, more intuitive menu system that includes a menu bar along the top of the screen with pull down menus that allow you to see all the commands available to you. Each of the menu groups contains commands that are similar or related in function. 2. The ability to have up to 9 documents or style sheets open at one time in overlapping windows, or 10 windows if you count the help window. 3. Easy referral to Help, in a window that can remain open as you work on your document. 4. A formatting ribbon that will allow you to immediately see what font or font size your text is formatted for, as well as allow you to easily format your text for a font, font size, or paragraph style from your stylesheet. 5. Speed-formatting keys for character formats. 6. A flashing underscore, instead of a single selected character (block), as its cursor to mark the insertion point. This eliminates the need for applying character formatting twice when you are trying to format a single character. The character window interface also follows a standard function key assignment that is consistent with our other Word products, such as Word for Windows and Word for the Macintosh. These function key assignments differ from the key assignments in Word 5.00, but to assist you in adjusting to this new interface if you are using Word 5.00, we have added the ability to retain the Word 5.00 function assignments. You choose this option either when you run the Setup program or by choosing the Customize dialog box from the Utilities menu and checking the box next to "Use Word 5.0 Function Keys". The functions of the DEL and INS keys are also different in the character window interface, where INS and DEL will NOT insert from or delete to the scrap. To retain the functionality of the INS and DEL keys available with Word 5.00, you can uncheck the box next to "Use INS for Overtype Key" in the Customize dialog box of the Utilities menu. This new interface will also pose a few hurdles for Word 5.00 macros. With the new interface, keystroke sequences to access Word's powerful word processing features have changed. To assist you in updating your Word 5.00 macros to run in Word 5.50, we have included the utility MACROCNV.EXE. This macro converter is meant only as a tool to assist you in converting your macros. Once you have converted macros with the macro converter, it will be necessary for you to review and edit your macros to optimize them to your exact needs. Please be aware that the macro converter cannot convert 100 percent of the commands in your macros. For more information about what is new with Word, please refer to Chapter 1 of the "Getting Started" pamphlet included with your Word 5.50 documentation. ====================================================================== EMAG10-2 Converting Word 5.00 Macros for Use in Word 5.50 by Charlie Gifford There are major differences between the Microsoft Word version 5.50 character windows interface and the Microsoft Word version 5.00 multitool interface. As a result, Word 5.00 macros converted by the macro conversion utility, MACROCNV.EXE, may not run correctly in Word 5.50. MACROCNV.EXE is a tool designed to help you convert Word 5.00 macros for use in Word 5.50. Some Word 5.00 macros may convert incorrectly or contain unnecessary commands that require editing before the macro is run in Word 5.50. After conversion, all macros should be executed with a test document. Be sure to make backup copies of any documents that are to be modified by a newly converted macro. The macro converter creates a backup copy of your Word 5.00 glossary files by renaming the Word 5.00 glossary with a "GL5" extension. Converted macros can be edited with the Word 5.50 Macro Edit command. Limitations and/or Potential Problems with the Macro Converter -------------------------------------------------------------- Speed keys (used to invoke the macro) assigned to Word 5.00 macros, may conflict with Word 5.50 built-in speed keys. Changing the speed keys that are assigned in the converted macro, or using CTRL+A before pressing the speed-key combination will solve this problem. If you have assigned the speed-key combination CTRL+A to a Word 5.00 macro, you should change this key combination to something new before running the converted macro in Word 5.50. Macros that use the F1 key to display a list of files in Word 5.00 will be converted so that the macro will pause and allow you to select a file from a files list box. Written or recorded macros that assume certain Word 5.00 menu settings will not convert correctly. The most common macro instruction that poses a problem for the macro converter is a recorded macro that selects menu options with the SPACEBAR, instead of the first letter of the menu option. "Run time" decisions made by Word while the macro is running may not convert correctly. For example, the ENTER key will be interpreted differently if Word is spell checking, in the Thesaurus or Gallery, or in the document view. There is no way for the macro converter to tell whether ENTER means to check the spelling of the next word, insert a paragraph mark in the document, or carry out a menu command. In the Word 5.00 Gallery, if you choose to format a style, Word recognizes at run time whether it is a character, paragraph, or section format and takes you to the appropriate menu. There is no way for the macro converter to identify the type of format chosen. Another run time decision is made with macros that set the promptmode variable to Yes. There is no way to determine the user's response to the prompt and guarantee a value for a macro variable. If a Word 5.00 macro changes several fields in one command menu, the Word 5.50 macro may have to choose more than one menu to make the same changes. For example, settings that can be accessed through the Word 5.00 Options menu may now require the macro to choose the Word 5.50 View and Utilities menus. Macro translation may be further complicated if you must press ENTER or ESC to leave a dialog box in Word 5.00. If the macro converter adds an ENTER-key press, additional options in Word 5.50 may be carried out unintentionally. If the macro converter adds ESC to a macro, options set in a dialog box may be canceled. Word 5.00 commands that may cause problems similar to these include Format Division Margins, Search, Replace, Options, and Print Options. Word 5.00 macros that involve moving, splitting, or sizing windows, and moving from window to window may not convert properly. Because of Word 5.50's support of overlapping windows, the Window Split Horizontal and Window Split Vertical commands are not valid for Word 5.50 and are ignored by the macro converter. The following Word 5.00 macro actions may not convert properly: selecting Library Document-Retrieval and changing the pathname, and using Transfer Allsave when glossaries, style sheets, or unnamed documents have not been saved. Macros containing nested macros and conditional statements may not be converted correctly. Most macros containing nested macros can be successfully converted if the macro is called from edit mode. If a function key is used to call a macro, the macro converter assumes that a built-in function is being used. The macro converter is restricted to one level of IF statements; nested IF statements cannot be converted. Workarounds ----------- If you edit a macro and still encounter problems executing the converted macro, you may want to consider recording the macro in Word 5.50. This may save you time in the long run. If you encounter problems converting a Word 5.00 macro, you can load your Word 5.50 document into Word 5.00, run your old macro in Word 5.00 on your Word 5.50 document, then load your modified document back into Word 5.50. This may be helpful if you are under a deadline to finish a document and don't have the time to edit the converted macro right away. ====================================================================== Word Version 5.50 by Microsoft Product Support Personnel EMAG10-3 Word 5.50: Viewing List Box Contents Without a Mouse (Word, Q67191) To view the contents of a drop down list box without the use of a mouse, do the following: Select the contents of the field and hold down the ALT key and press the DOWN ARROW key (ALT+DOWN ARROW). This will display a list of options available to this field. Example 1 --------- To view the list of available fonts in the Format Character dialog box: 1. From the Format menu, choose Character (ALT, T, C). 2. Hold down the ALT key and press the DOWN ARROW key (ALT+DOWN ARROW). A list of available fonts will now appear in a drop down list box. Example 2 --------- To view the list of available fonts from the ribbon: 1. Activate the ribbon (if not active) with ALT+V+B. 2. Hold down the CTRL key and press the F key (CTRL+F). 3. Hold down the ALT key and press the DOWN ARROW key (ALT+DOWN ARROW). A list of available fonts will now appear in a drop down list box. ====================================================================== EMAG10-4 Word 5.50: Installing Mouse Driver and Updating System (Word, Q66066) When running the Word 5.50 Setup program for a DOS-based computer system with a mouse pointing device, select the "Update the mouse driver" and "Update the system files" options to ensure that the updated mouse driver is installed properly. If the "Update the mouse driver" option is selected and the option to "Update the system files" is not selected, the Setup program will only copy the updated mouse driver (MOUSE.SYS) to the Word program directory and not add the necessary device line to the CONFIG.SYS file to use the new mouse driver. To add the device line to the CONFIG.SYS file, the Setup program can be run with the option to "Modify an existing version of Word." Choose to "Install a mouse" and have the Setup program modify the system files. (You can also manually add a line to the CONFIG.SYS file to include the path to the updated MOUSE.SYS file, that is, device=c:\mouse.sys). If the mouse being used is not a Microsoft or IBM PS/2-compatible mouse, it is strongly suggested that the manufacturer's mouse driver be used. If there are problems relating to a manufacturer's mouse in Word, contact the manufacturer of the mouse regarding a possible updated mouse driver to use with Microsoft Word version 5.50. Microsoft System Diagnostics can be used to determine the mouse driver version that is being loaded on startup. ====================================================================== EMAG10-5 Word 5.50: New Command-Line Switches (Word, Q66133) The following is a list of new command-line switches for Microsoft Word version 5.50. To use any of the following switches, type "word /(switch)" at the command prompt (for example, "word /z"): Switch Function ------ -------- /i Turns cursor blinking off in graphics mode. /m (macroname) Loads a macro from NORMAL.GLY automatically on startup. /p Uses Word 5.50 function keys and uses INS to toggle Overtype. /t Uses Word 5.00 function keys and uses INS to insert text from scrap. /w Ignores line spacing at the top of a page so that when the last line in the window is reached, Word wraps text to the top of a new window and starts a new line. /z Returns all switches back to the Word 5.50 defaults. Additional switches available in previous versions of Microsoft Word and Word version 5.50: Switch Function ------ -------- /bn Specifies the number of internal page buffers for expanded memory (number between 4 and 1500). /k Disables an enhanced keyboard. /l Opens the last document edited during the last Word session. /n For use with a Novell network. /x Disables expanded memory. /y Enables Word 4.00 scrolling. ====================================================================== EMAG10-6 Word 5.50 Freeing Up Memory When Shelling Out (Word, Q66065) When selecting DOS commands or OS/2 commands from the File menu in Microsoft Word version 5.50, include the extension of the program to run from the operating system shell (for example, COMMAND.COM instead of COMMAND) in order to free up memory. If the file extension (.COM, .EXE) is included, Word will throw away its page buffers and close any open files, making more memory and file handles available to programs executed from the operating system shell. Because Word 5.50 will close any open files if the file extension is included, you must be careful not to modify any files that will be reopened by Word when the operating system shell is exited and control is returned to Word. If a file is modified, Word may be unable to continue or the file may become corrupted. Page buffers are 512-byte blocks of memory that contain document text. The number of page buffers created by Word is determined by the amount of memory available. If no expanded memory is available, the size of the page buffers cannot exceed 64K. When Word throws away its page buffers to execute an operating system shell, approximately 50K of memory will be freed. File handles are 16-bit numbers that the operating system uses to identify open files and/or to identify other input/output sources for a program. The default internal data structure for DOS only allows for eight file handles. The number of file handles can be increased with the use of the FILES command in the CONFIG.SYS file (for example, Files=20). ====================================================================== EMAG10-7 Word 5.50: Setup Does Not Overwrite Word Version 4.00 (Word, Q67157) The Setup program for Microsoft Word version 5.50 will not overwrite an existing installation of Word version 4.00 or earlier. If a previous version of Word (version 4.00 or earlier) exists in the same subdirectory that Word version 5.50 is installed in (for example, C:\WORD), the program files of the previous version are not overwritten. To manually remove the previous version of Word, delete or rename the WORD.COM and WORD.PGM files from the Word program directory. This will not affect the Word version 5.50 installation because the Word version 5.50 executable file is WORD.EXE. The "Install a new version of Word" option in the Word 5.50 Setup program only overwrites the Word version 5.00 program file (WORD.EXE). ====================================================================== EMAG10-8 Decompressing Word 5.50 Files with Setup (Word, Q64464) The majority of the files on the Word 5.50 disks are compressed, and can be distinguished from the uncompressed files on disk by the dollar sign ($) that occupies the last character position in the file extension. The Setup program will automatically decompress a compressed file when it copies the file to disk during the installation of Word 5.50. Setup can also be used to decompress a file, using the following command syntax: SETUP /d [source file] [destination file] Setup must be able to locate the WORD55.INF and PRD.INF installation information files in the directory from which it is invoked. If these files cannot be found, Setup will display the message "Information file is not in current directory" and will not properly decompress the file. If no destination file is specified when Setup is invoked, Setup will create an uncompressed file on disk with the name that is stored in the compressed file's header. ====================================================================== EMAG10-9 WORD.PIF Settings for Windows 3.00 (Word, 65737) Microsoft Word version 5.50 includes a Program Information File (PIF) called WORD.PIF for use with Microsoft Windows version 3.00. Because Word 5.50 is a non-Windows application, it is strongly recommended that Word 5.50 be started from WORD.PIF when running Word from Windows 3.00. To set up Word 5.50 to run from the Windows 3.00 "Non-Windows Applications" group using WORD.PIF, follow these steps: 1. From the Window menu of the Windows 3.00 Program Manager choose "Non-Windows Applications" (another group name may be substituted). 2. From File menu of Program Manager, select New. 3. Select Program Item, and click OK or press ENTER. 4. The Program Item Properties screen will appear. Beside the Description field, type "Word 5.50". The contents of the Description field are optional. The description text that is entered will appear under the icon associated with the Word 5.50 program item. Beside the Command Line field, type the drive and directory path to the location of WORD.PIF (for example, C:\WORD\WORD.PIF). 5. Select OK. A new program item icon will appear in the active group (Non- Windows Applications). Word can now be started from Windows by double-clicking the new icon. WORD.PIF settings (for use with Windows 3.00) are as follows: Program Filename: WORD.EXE Window Title: Microsoft Word 5.5 Optional Parameters: None Start-up Directory: None Memory Requirements: KB Required: 384 KB Desired: 640 Display Usage: Full Screen Execution: Exclusive Close Window on Exit: Yes Note: SETUP.EXE does not modify the WORD.PIF settings to reflect any options selected or specified during installation. The Windows 3.00 PIF Editor can be used to customize the WORD.PIF included with Word 5.50. Use the Start-Up Directory and Optional Parameters fields to customize the WORD.PIF file. Changing the memory requirements in the KB Required field to a value less than 384 KB (kilobytes) is not recommended. The following are Advanced Options (available under 386 enhanced mode only): Multitasking Options: Background Priority: 50 Foreground Priority: 100 Detect Idle Time: Yes Memory Options: EMS Memory: KB Required: 0 KB Limit: 1024 Locked: No XMS Memory: KB Required: 0 KB Limit: 1024 Locked: No Uses High Memory Area: Yes (checked) Lock Application Memory: No (unchecked) Display Options: Video memory: High Graphics Monitor Ports: Text (checked), Low Graphics (checked) Emulate Text Mode: Yes (checked) Retain Video Memory: Yes (checked) Note: Word 5.50 can access expanded memory (EMS) that meets the Lotus- Intel-Microsoft (LIM) specification versions 3.20 or later. To allow Word to access expanded memory when running under Windows 386 enhanced mode, indicate a value (other than zero) in the Advance Options, EMS Memory (KB Required) section of the PIF file. Word 5.50 does not use extended memory (XMS). The following are other options: Allow Fast Paste: No (unchecked) Allow Close When active: No (unchecked) Reserve Shortcut Keys: ALT+TAB: No (unchecked) PRTSC: No (unchecked) ALT+ENTER: No (unchecked) ALT+ESC: No (unchecked) ALT+PRTSC: No (unchecked) CTRL+ESC: No (unchecked) ALT+SPACE: Yes (checked) Application Shortcut Key: None ====================================================================== What's New by Microsoft Product Support Personnel EMAG10-10 Accessing Program Segment Prefix in OS/2 Bound Program (OS/2 SDK, Q66821) Question: I have a bound application program that runs in OS/2 and MS-DOS. This program is a type of "shell" that spawns other programs. However, in MS-DOS, the shell takes up too much memory to run large programs, such as the Microsoft C Compiler version 6.00. Therefore, I am interested in using the do_exec and do_spawn functions that were presented in the article by Marc Adler in the September 1990 issue of the "Microsoft Systems Journal," titled "Spawn Programs from Within Your DOS Application Using Almost No Additional Memory." I have downloaded the source code and examined it. It uses some C run- time functions such as INTDOS and INTDOSX that are not in the protected mode versions of the C run-time libraries. This is no problem because I can substitute FAPI calls for them to get the information they need. However, the SPAWN.ASM module needs to access the program segment prefix (PSP), and it tries to get the PSP's address by referencing the external variable _psp. This variable is not defined in the protected mode C run-time libraries. I assume that it was omitted because protected mode programs running in OS/2 really have no need to access the PSP. What about a bound version of the program running in MS-DOS? Is the PSP the same, and if it is, is there any way a bound program can access it (perhaps through a register)? Will the technique used in the do_spawn function to swap programs in MS-DOS work at all for a bound program? If it will work, how should I adapt the code? Response: You are correct that the run-time library global variable _psp has been removed from the protected mode run-time libraries; OS/2 programs do not have a PSP. However, a bound program does construct a PSP for compatibility with older MS-DOS programs; you just don't have a _psp to use to get to it. However, you can call MS-DOS interrupt 0x21 function 0x51 to get the address of your PSP when you are running a bound program in real mode or under MS-DOS. If you put 0x51 into AH and call INT 21, the segment of your PSP is returned in BX. The offset of the PSP into that segment is 0 (zero). Be sure to call DosGetMachineMode() before calling this interrupt. You cannot call this interrupt while running in protected mode. The following is a small sample program that shows how to access the PSP using this interrupt in a bound program: #define INCL_DOSMISC #include #include #include #include #include main() { BYTE bMachineMode; USHORT usPspSeg; if (DosGetMachineMode(&bMachineMode)) { puts("error in DosGetMachineMode()"); exit(1); } if (bMachineMode == MODE_REAL) { _asm { mov ah, 51h int 21h mov usPspSeg, bx } printf("PSP = 0x%04x\n", usPspSeg); } return(0); } ====================================================================== EMAG10-11 COM/Serial Port Detection in OS/2 (OS/2 SDK, Q66236) Question: Is it possible to determine if a physical COM board is installed for a given COM/serial port? I have a program that requests, and is granted, access to read/write to COM2 (0x2f8 -> 0x2f2) via the DosPortAccess() function. Access is granted, but on some machines (not all), if a COM2 port is not physically installed, a protection fault is produced. Response: It is possible to do this, but you shouldn't use the DosPortAccess() function. DosPortAccess() is essentially an NOP that always returns success. It has been abandoned in OS/2 version 2.00. One of the easiest ways to detect if a COM port is present is to try to open the port using the DosOpen() function. By checking the return code value, you should be able to detect whether the hardware is present. Another more difficult method is to actually write to the port registers and read back the expected results. This involves setting up IOPL segments in your application. This method is supported in OS/2 versions 1.10 and 1.21. For more information, please refer to Chapter 14 of "Advanced OS/2 Programming" by Ray Duncan. This will help you set up the segments properly. You then must decide which register you want to write to. On an 8250, there is a scratch register that is safe to read and write to. For COM2, the I/O address is 0x2FF. It is always the last register you can write to, 0xXXF. The 8250 is probably the most common chip used for COM ports on PCs. However, it is starting to be replaced by 16450s and 16550s. ====================================================================== EMAG10-12 PM: Determining Which Button Is the Default or Focused Button (Presentation Manager, Q65966) Question: In my dialog box, I have some entry fields and some buttons. By using the TAB key, I can navigate through entry fields and buttons. When I come to a button, the button gets the focus (a dotted-line cursor is inside) and the button becomes the default (a heavy dark border is displayed). I have some buttons that I do not want to ever become the default buttons -- just focused (that is, callable with the SPACEBAR key and not with the ENTER key). How can I disallow buttons from becoming the default button? Also, how can I query the dialog box to find out which button is the default or focused button? Response: The message you should be concerned with is BM_SETDEFAULT. This message is sent to a button when that button is about to become the default button. You can disallow buttons from becoming the default button by subclassing the button. Send most messages through to the old button window procedure. However, screen out the BM_SETDEFAULT message. If this message does not get through to the old window procedure, then the button will not become the default. Simply subclassing one button in order to cause it to refuse accepting the default will result in a situation in which no button has the default. For this reason, you may want to send this same message to some other button at the time your button screens it out. A button that has the default has the BS_DEFAULT style bit turned on. You may get all of the style bits for any window by using WinQueryWindowULong(., QWL_SYTLE). Obviously, you will have to step through and check each one of the button HWNDs. The best way to determine focus is by using the WinQueryFocus() call. This method is different from the above method in that only one call is required, and the result you receive will not necessarily be an HWND in your own application. ====================================================================== EMAG10-13 Adding and Removing FCF_SIZEBORDER Style of a PM Frame Window (Presentation Manager, Q66464) Question: How can I update the frame controls of a window already on the screen? Also, how can I obtain the frame-style bits so that I can change from a size border to no border, and vice versa? Response: You need to change the style bits and send a WM_UPDATEFRAME message to the frame. Adding or removing the size border from a frame window is a little different from adding or removing other frame controls. This is because the size border is not a window. Therefore, you do not need to destroy any windows, as you would if you were to remove the MINMAX button. The following is the code you need to add to perform this type of functionality: ; Remove the size border. WinSetWindowBits( hwndFrame, QWL_STYLE, ~FS_SIZEBORDER, FS_SIZEBORDER ); WinSendMsg( hwndFrame, WM_UPDATEFRAME, MPFROM2SHORT( FCF_SIZEBORDER, 0 ), 0L ); ; Add the size border. WinSetWindowBits( hwndFrame, QWL_STYLE, FS_SIZEBORDER, FS_SIZEBORDER ); WinSendMsg( hwndFrame, WM_UPDATEFRAME, MPFROM2SHORT( FCF_SIZEBORDER, 0 ), 0L ); ====================================================================== EMAG10-14 Memory Requirements for Real-Mode CodeView (CV.EXE) (CodeView, Q66513) Real-mode versions of CodeView (CV) beginning with version 3.00 offer a number of ways to utilize available memory in order to make the greatest amount of conventional memory available to the program being debugged. The amount of memory actually used depends on the command- line options specified as well as the configuration of the system used for debugging. The following table shows the size of CodeView in standard DOS memory with each of the memory-specific command-line options (see below for further details): Option RAM Usage Option RAM Usage ------ --------- ------ --------- /X 16K /D16 210K /E 192K /D32 225K /D 256K (same as /D64) /D128 320K The following descriptions of the three memory-related CodeView options explain the ways in which each option affects memory utilization in addition to the respective amounts of conventional memory that CodeView requires with each. (This information pertains only to CodeView versions 3.00 and later -- versions of CodeView earlier than 3.00 require approximately 230K of RAM specifically for CodeView.) /X - Specifies that CodeView should utilize extended memory. Assuming that enough extended memory is available, this option moves both the symbolic information and most of CV itself into extended memory. Allowing CV to be loaded into high memory requires that approximately 16K to 19K of "control" code remain in conventional memory; thus all free conventional RAM over 19K is available to load the program to be debugged (the "debuggee"). /E - Specifies that CodeView should utilize expanded memory. Assuming that enough expanded memory is available, this option moves both the symbolic information and CodeView's own overlays into expanded memory. The size of the CV "root" without the extra overlayed code is approximately 192K. Since the overlays do not cause any additional overhead with /E, all free conventional RAM over 192K is available to load the debuggee. /D - Specifies that CodeView should utilize disk overlays in conventional memory. By default, this option creates a 64K buffer area for loading disk overlays. With the 192K root, the 64K buffer means CV will take about 256K of conventional memory with /D. In addition, the symbolic information must also be loaded into conventional memory; therefore, since symbolic data varies with each program, it is not possible to specify the amount of memory available for the debuggee alone. The /D option can also be specified with a value that indicates the size of the overlay buffer area. This parameter can be any value from 16 to 128, which represents an overlay buffer size from 16K to 128K. Specifying /D16 will minimize CodeView's size with disk overlays to approximately 210K. This maximizes the amount of conventional memory that will be available to load the debuggee and the symbolic information. At the other extreme, /D128 causes CV to use approximately 320K of conventional RAM. This provides faster CodeView execution speed, but it will only work with smaller debuggees. Note: CodeView will default to the best memory usage possible. In other words, if NO memory usage option is specified, CV will try to use extended memory. If extended memory is unavailable, CV looks for expanded memory. CV will use disk overlays on its own only if expanded memory is not found. ====================================================================== EMAG10-15 How to Add Other Language Compilers to PWB's Build Options (PWB, Q65568) The Programmer's WorkBench (PWB) is an environment capable of utilizing different compilers for mixed-language programming. When installed during BASIC version 7.10 setup, PWB version 1.10 shows build options for the BASIC language only. However, it is possible to include other language compilers to utilize the full features of the PWB utility. The following information applies to the Programmer's WorkBench version 1.10 utility supplied with Microsoft BASIC Professional Development System (PDS) version 7.10 for MS-DOS and MS OS/2. Note that the 1.00 version of PWB is shipped with Microsoft C Professional Development System (PDS) version 6.00. The steps below should also apply to PWB version 1.00. The Programmer's WorkBench (PWB.EXE) is an advanced development environment capable of integrating several language compilers, NMAKE.EXE, LINK.EXE, and the CodeView debugger. It offers the ability to accomplish tasks, such as program development under protected mode and mixed-language programming. This ability is not available in the QuickBASIC extended development environment (QBX.EXE). Two special files, PWBC.PX$ (for protected mode OS/2) and PWBC.MX$ (for DOS mode), reside on the BASIC PDS 7.10 disks and support the option of using the C compiler in PWB. Since SETUP.EXE (in BASIC PDS 7.10) does not copy PWBC.PX$ and PWBC.MX$ during installation, these files must be unpacked and transferred to your machine; for example, to the \BINP subdirectory located in the \BC7 directory. (Note: The UNPACK.EXE utility is found on disk 1 of the BASIC PDS package.) After unpacking, the files will have the names PWBC.PXT and PWBC.MXT. Next, the following command lines must be added to the TOOLS.INI file to make the C compiler available to PWB: [pwb - .BAS .BI] LOAD: LogicalDrive:\[Path]\PWBC.PXT For further information about installing PWBC.PXT and PWBC.MXT, see page 54 of the "Microsoft BASIC 7.1: Getting Started" manual. If you want to program in languages other than BASIC or C (such as Microsoft Macro Assembler [MASM], Microsoft Pascal, Microsoft FORTRAN, or Microsoft COBOL 3.00/3.00a), the following steps will insert the initial build options to include other languages in PWB's build options menu. In the example below, options to include the MASM.EXE assembler are specified. If some other language's compiler is desired, substitute appropriate changes for that compiler, where noted in the specified areas. 1. In PWB, go to the Options menu and select Build Options. 2. Choose Save Current Build Options. 3. Enter a meaningful message, such as "Options to Include MASM" in the window's edit field (if some other language is desired, change MASM to the appropriate name). Select the OK button from the Save Current Build Options and Build Options windows. 4. Open the TOOLS.INI file in the PWB utility and go down to the bottom of the file. Somewhere near the bottom should be the tag "[PWB-Build Options: Options to Include MASM]" (or the language that was specified). 5. In this section, add the following NMAKE instructions: build: inference .asm.obj masm_asm_obj build: command masm_asm_obj "masm $<;" Note: For languages other than MASM, distinguish a variable name in the inference rule to be used in the commands line (like masm_asm_obj has been used above) and then specify the appropriate compiler in the commands line within the quotation marks. The special filename macro specified in the quotation marks, "$<", applies the command to any object that has an out-of-date executable file. 6. Press SHIFT+F8 to reinitialize the file; and then close it. 7. Go to the File menu and select New (it is a good idea to close any lsfiles that are currently open before doing this step). 8. Go to the Options menu and select Build Options. 9. Choose Initial Build Options. 10. Select the "Options to Include MASM" option (it should be near the bottom of the list). After completing these instructions, the PWB utility will now be ready to compile assembler along with BASIC source code, provided that paths to the necessary compilers are furnished. ====================================================================== EMAG10-16 What Happens to Stack Memory When Thread Terminates? (C Compiler, Q66295) Question: If I call _beginthread() with NULL as the second parameter, the run time is supposed to create a thread stack for me. How is this done? Also, when the thread terminates with _endthread(), is the memory automatically released back to the operating system? Response: If _beginthread() is called with NULL for the thread stack, a stack of size stack_size (passed as the third parameter) is malloc()'ed from the heap. At the time the thread is terminated, the stack is still in use; therefore, _endthread() does not automatically free it. In fact, the last things _endthread() does are to push the appropriate arguments onto the stack and call DosExit(). However, the memory is recovered. The next time that thread ID is used, _beginthread() will check to see if the thread stack was previously malloc()'ed internally by the function. If so, it will call free() at that time. Note that the thread memory doesn't go to the operating system; instead, it is returned to the heap. Due to the fact that OS/2 will use a thread ID from terminated threads first, there will usually be only one thread stack not free()'ed. As a side note, in 32-bit OS/2, this is all a moot point. The 32-bit DosCreateThread() API call will automatically allocate/deallocate the thread stack. ====================================================================== EMAG10-17 Using _psp for Pointer Checking (C Compiler, Q66127) Problem: I want to implement my own pointer checking routine. If the PSP (program segment prefix) is set up in the lowest segment of available memory, then I should be able to use _psp as the lower bounds for legal pointer segments. However, if I write a program that compares _psp with pointer segments returned by malloc(), I get back segment values less than _psp. Response: When DOS loads an .EXE or .COM file, the PSP is set up in the lowest segment of the largest contiguous block of available memory. There may be other blocks of available memory below the location of the PSP; however these blocks of memory are usually fairly small. If DOS returns one of these segments, when pointer checking is implemented with the /Zr option (available only with the /qc compiler option), the segment is simply discarded and DOS is called again. This process is repeated until a segment value greater than _psp is returned. You can implement a similar routine in any C program by making calls to a function, as demonstrated below, rather than making calls directly to malloc(). However, the start-up code still will make calls to malloc() directly for environment and argument space. Thus, the pointer segments for the environment and arguments may still be less than _psp. Further, it should be noted that this routine does not implement pointer checking; it only enables programmers to implement their own pointer checking by comparing segment values against _psp. Another method of getting only pointer segments greater than _psp is to modify the start-up code so that the value of _psp is stored at _aseglo. This is the actual location used to store the lower segment limit when pointer checking is implemented. The code to check the segment returned by DOS against this location, and to call DOS again if necessary, is already implemented. If it is necessary to have pointer segments for the environment and argument variables greater than _psp, a similar assignment can be used to modify the start-up code. If this assignment is done before the space for these variables is allocated in the start-up code, they will have segment values greater than _psp. However, you should be aware that Microsoft can make no guarantees about the implementation of this feature in any future releases. If a call to malloc() requires a new segment to be allocated from the operating system, the call to DOS will be made requesting only the amount of memory required by the malloc(). In subsequent calls, requests are made for 8K blocks of memory until no more memory is available from that segment. Since the blocks of memory below the PSP are small, they may not be allocated during the first calls to malloc(). Thus, you cannot be sure exactly when these blocks of memory will be allocated. Code Example ------------ void * _new_malloc (size_t size) { void * temp_ptr; temp_ptr= malloc (size); while ((temp_ptr != NULL) && (FP_SEG(temp_ptr) < _psp)) temp_ptr= malloc (size); return temp_ptr; } ====================================================================== EMAG10-18 Differences/Enhancements from BASIC PDS 7.00 to 7.10 (BASIC Compiler, Q65598) In August 1990, Microsoft released the Microsoft BASIC Professional Development System (PDS) version 7.10 for MS-DOS and MS OS/2 systems. This article documents those features that were added to BASIC PDS 7.10 that are not supported in BASIC PDS 7.00. The lists below are titled "Language Enhancements," "New Utilities and Utility Improvements," and "Software Corrections." This information applies to Microsoft BASIC Professional Development System version 7.10 for MS-DOS and MS OS/2. Language Enhancements --------------------- 1. REDIM PRESERVE changes the upper bounds (top-right dimension) of a $DYNAMIC array and preserves the data in the array. Previous versions of BASIC initialized the array to zeroes or null strings on a REDIM. 2. It is now possible to pass fixed-length-string arrays as parameters to SUB and FUNCTION procedures. 3. A CALL by value using BYVAL for BASIC SUB and FUNCTION subprograms is now possible. Previously, BASIC only supported CALL by value using BYVAL when calling a non-BASIC language such as C. The BYVAL attribute for passed parameters is now allowed when calling a BASIC SUB or FUNCTION. 4. ISAM is now supported under OS/2. ISAM in PDS 7.10 can be used in OS/2 protected mode. (Note that ISAM in PDS 7.10 is still single- user ISAM as in 7.00.) 5. ISAM support in 7.10 operates up to 50 percent faster than in 7.00, depending on the program. 6. Communications input is buffered during a SHELL if the program was compiled with the BC /O (stand alone) option. All previous versions of BASIC disabled communications support and buffering of communications data during a SHELL. BASIC PDS 7.10 does not, however, buffer communications data during a SHELL if you are using the run-time module (BRT71xxx.EXE). 7. BASIC PDS 7.10 now allows interlanguage calling to functions created with Microsoft C Compiler version 6.00. (BASIC PDS 7.00 only allowed calling to Microsoft C Compiler version 5.10 functions.) New Utilities and Utility Improvements -------------------------------------- 1. QBX.EXE improvement: The 7.10 QuickBASIC extended (QBX.EXE) environment uses expanded memory more efficiently than 7.00. In BASIC PDS 7.00, each subprogram from 1K to 16K in size uses a full 16K of expanded memory. In BASIC PDS 7.10, subprograms smaller than 16K will use expanded memory in 1K chunks. In 7.10, if a subprogram is 2K in size, it will use only 2K of expanded memory. (Subprograms larger than 16K are stored in conventional memory in both 7.00 and 7.10.) 2. Programmer's WorkBench (PWB), a new utility: The Programmer's WorkBench is the integrated development environment that is provided with Microsoft's newest "high-end" language products. It integrates the following features: - Keyboard-driven or mouse-driven control of the WorkBench through use of menus and scroll bars. - Ability to launch other utilities from PWB, such as NMAKE or CodeView. - Context sensitive online Help. - Multiple windows for managing multiple files for large projects. - Multiple-language development within PWB. - Supports development under both DOS and OS/2. - Customizable program editor. - Combines Microsoft's Quick environments (such as QuickBASIC and QuickC) and the Microsoft Editor, providing easier learning for anyone familiar with those environments. However, PWB offers many features over and above the Quick environments and the earlier Microsoft Editor. 3. Source Browser: Source Browser is a powerful cross-referencing tool that can be launched from within PWB. 4. The CodeView 3.10 debugger is included. 5. NMAKE facility: A superset of the earlier Microsoft MAKE facility. PWB saves you the inconvenience of remembering makefile syntax by building and maintaining makefiles for you. 6. QuickHelp: QuickHelp allows you to access online documentation without running QBX.EXE or PWB.EXE. QuickHelp can be run from the DOS or OS/2 command line and can also be installed as a keyboard monitor under OS/2. Any Help files with the correct format can be used with QuickHelp. 7. QBX.EXE improvement: In the QBX environment under the Run menu, the Make .EXE File command now lets you set any BC.EXE compiler option in the "Additional Options:" field. Software Corrections -------------------- For a list of known problems with BASIC PDS 7.00 (or QuickBASIC 4.50) that are corrected in BASIC PDS 7.10, query on the word "fixlist7.10". ====================================================================== EMAG10-19 How SUB and FUNCTION Windows Inherit DEFtype in QB.EXE Editor (QuickBASIC, Q47491) The following information applies to the QB.EXE editor in QuickBASIC versions 4.00, 4.00b, and 4.50; to the QB.EXE editor in Microsoft BASIC Compiler versions 6.00 and 6.00b; and to the QBX.EXE editor in Microsoft BASIC Professional Development System (PDS) versions 7.00 and 7.10. When creating SUB or FUNCTION procedures in the QB.EXE or QBX.EXE editor, the procedures inherit the DEFtype statement shown in the window in which they were first created. DEFtype refers to the following statements: DEFINT, DEFLNG, DEFSNG, DEFDBL, DEFSTR, and DEFCUR. (DEFCUR, which is a declaration for the CURRENCY data type, is supported only in BASIC PDS 7.00 and 7.10.) If no DEFtype statement is visible in a window, the default DEFSNG A-Z applies. If a certain range of letters is not covered by a DEFtype statement in the current window, then that range of letters is covered by DEFSNG (since single precision is the default data type). For more information in a related article, query on the following words: DEFLNG and MISMATCH and $DYNAMIC If the module-level code for the current module contains a DEFINT A-Z statement, any SUB or FUNCTION created in that module automatically has a DEFINT A-Z statement placed just above the SUB or FUNCTION line. If a SUB or FUNCTION is created and moved to a module (source file) with a different DEFtype than the module it was created in, the SUBprogram and its new module have different default variable types, and SHARED or passed variables may not be recognized in the SUBprogram. In this case, the variables that were intended to be SHARED may have the same name in both the SUBprogram and the module, but the variables are of different types and, thus, are considered different variables. You may encounter this same situation if you create a SUBprogram (which "inherits" the module-level DEFtype) and then change the DEFtype at the module level. To avoid problems accessing SHARED or passed variables, you can either append the appropriate type-specifier character (%, &, !, #, or $) to the variable name, or make sure that all your SUBprograms have the same DEFtype as the module that calls them. Code Example ------------ Executing the following code prints the values 0 and 10, whereas you may have wanted 10 and 10. The reason for the difference is that while Y% is always an integer variable (the "%" type specifier ensures this) and, thus, is recognized as the COMMON SHARED variable Y% in the subprogram, "X" is an integer (because of the DEFINT) at the module level, and a double-precision variable (because of the DEFDBL before the SUB) in the SUBprogram. Thus, Y% is recognized as SHARED and changed correctly, while X is considered a local variable in the SUBprogram and the COMMON SHARED variable X remains unaltered. 'Module-level code: DEFINT A-Z COMMON SHARED X, Y% CALL thesub PRINT X, Y% END 'SUBprogram level in same module -- different DEFtype statement: DEFDBL A-Z SUB thesub X = 5 Y% = 10 END SUB ====================================================================== EMAG10-20 Description of Stub Files and How They May Enlarge EXE (BASIC Compiler, Q62908) The stub files provided with Microsoft BASIC Professional Development System (PDS) versions 7.00 and 7.10 for MS-DOS should be used only under specific circumstances. If used incorrectly, linking with the stub files may actually increase the size of the executable file. A file in the Software/Data Library explains when to link with stub files, the effects of each of the stub files, and when linking each stub file may increase or decrease the size of a program. This file can be found in the Software/Data Library by searching on the word STUB700, the Q number of this article, or S12609. STUB700 was archived using the PKware file conversion utility. Please see the file mentioned above in the Software/Data Library for more specific information about when to use the following BASIC PDS 7.00 and 7.10 stub files: NOCGA.OBJ, NOEGA.OBJ, NOOGA.OBJ, NOHERC.OBJ NOVGA.OBJ NOGRAPH.OBJ NOCOM.OBJ, NOLPT.OBJ SMALLERR.OBJ 87.LIB NOEVENT.OBJ NOEMS.OBJ OVLDOS21.OBJ NOFLTIN.OBJ NOEDIT.OBJ TSCNIONR.OBJ TSCNIOFR.OBJ TSCNIONP.OBJ TSCNIOFP.OBJ NOTRNEMR.LIB NOTRNEMP.LIB NOISAM.OBJ Most stub files are useful only when you are compiling for use with BCL7nxxx.LIB (compiling with BC /O) or making a customized run-time module. When you compile for use with the default BRT7nxxx.EXE run- time module, the support for BASIC language features is already built into the run-time module and cannot be stubbed out without rebuilding (customizing) the run-time module itself. (Two exceptions to this are NOEMS.OBJ and OVLDOS21.OBJ, which affect overlay support in the BASIC compiled executable .EXE program and don't affect the run-time module.) ====================================================================== EMAG10-21 Which BASIC Versions Can CALL C, FORTRAN, Pascal, MASM (QuickBASIC, Q35965) Certain versions of Microsoft QuickBASIC and Microsoft BASIC Compiler can CALL routines from certain other Microsoft languages (and pass parameters), depending upon the product version number, as explained below. Microsoft BASIC Professional Development System (PDS) version 7.10 can be linked with Microsoft C PDS version 6.00 or QuickC version 2.50 or 2.51. The following application note, which can be requested from Microsoft Product Support Services, is required if you want to perform BASIC 7.10 mixed-language programming with C 5.10, FORTRAN 5.00, or Pascal 4.00: "How to Link BASIC PDS 7.10 with C 5.10, FORTRAN 5.00, or Pascal 4.00" (application note number BB0345) QuickBASIC 4.50 and BASIC PDS 7.00 (but not earlier versions) can create .OBJ modules that can be linked with .OBJ modules from Microsoft FORTRAN version 5.00 and Microsoft QuickC version 2.01. QuickBASIC versions 4.00b and 4.50, Microsoft BASIC Compiler versions 6.00 and 6.00b for MS-DOS and MS OS/2, and Microsoft BASIC PDS version 7.00 for MS-DOS and MS OS/2 create .OBJ modules that can be linked with .OBJ modules from the following languages: 1. Microsoft Pascal version 4.00 2. Microsoft FORTRAN version 4.10 3. Microsoft C version 5.10 and QuickC versions 1.01 and 2.00 4. Microsoft Macro Assembler (MASM) version 5.00 or later recommended, but earlier versions should also work For more information on interlanguage CALLing between Microsoft C and BASIC, query on the word "BAS2C". For more information on interlanguage CALLing between Microsoft MASM and BASIC, query on the word "BAS2MASM". For more information about using the CALL statement to pass parameters from BASIC to other languages, query on the following words: CALL and (PASSING or PASS) and [language name] QuickBASIC 4.00 --------------- QuickBASIC version 4.00 creates .OBJ modules that can be linked with .OBJ modules from the following languages (Microsoft has performed successful interlanguage test suites for QuickBASIC version 4.00 with these language versions): 1. Microsoft C version 5.00, QuickC version 1.00 2. Microsoft FORTRAN version 4.00 3. Microsoft Pascal version 4.00 4. Microsoft Macro Assembler (MASM) versions 4.00 and later recommended, but earlier versions should also work Note that QuickBASIC version 4.00b might link with these earlier language versions, but Microsoft cannot guarantee success because the 4.00b test suites were performed only on the later language versions mentioned further above in this article. QuickBASIC 1.x, 2.x, 3.00 ------------------------- In QuickBASIC versions 1.00, 1.01, 1.02, 2.00, 2.01, and 3.00, you can link only to .OBJ modules from Microsoft Macro Assembler (versions 1.2x, 2.x, or later) or the given version of QuickBASIC. In other words, QuickBASIC versions 3.00 and earlier can CALL only QuickBASIC subprograms or assembly routines. Important Information About Interlanguage CALLing ------------------------------------------------- To be compatible with compiled BASIC, programs should be assembled or compiled using the medium, large, or huge memory model, and BASIC must be linked first (as the main module). When you link compiled BASIC to other compiled BASIC modules, compiler versions should not be mixed. For example, an .OBJ module compiled in QuickBASIC version 4.00 should not be linked with an .OBJ module compiled in QuickBASIC version 4.00b or 4.50 or Microsoft BASIC Compiler version 6.00 or 6.00b or Microsoft BASIC PDS version 7.00 or 7.10. As an alternative to the CALL statement for interlanguage invocation, you may use the SHELL statement to invoke most (non-TSR) .EXE, .COM, or .BAT programs that you can also invoke from DOS. SHELL works differently than CALL. SHELL invokes another copy of the DOS COMMAND.COM command processor before running a requested executable program.