View source for Question and Answers - August 1993

''By [[IBM]]''

'''Q. Which CD-ROM drives does OS/2 2.1 support?'''

A. Although the list of OS/2 2.1-supported CD-ROM drives is constantly growing, the following list is accurate as of press time:
* CD Technology (Model T3301)
* Hitachi (Models CDR-1650S, CDR-1750S, CDR-3650, and CDR-3750)
* IBM (All models)
* NEC (Models CDR-25, CDR-36, CDR-37, CDR-38, CDR-72, CDR-73, CDR-74, CDR-82, CDR-83, CDR-84, Multispin 38, Multispin 74, and Multispin 84)
* Panasonic (Models CR-501, LK-MC501S, MC501B, and MC521)
* Pioneer (Models DRM-600 and DRM-604X)
* Sony (Models CDU-541, CDU-561, CDU-6111, CDU-6211, and CDU-7211)
* Texel (Models DM-3021, DM-3024, DM-5021, and DM-5024)
* Toshiba (Models XM-3201, XM-3301, and XM-3401)
These CD-ROM drives must be attached to IBM, Future Domain, Adaptec, DPT, or other SCSI adapters with native OS/2 2.1 support.

Additionally, OS/2 2.1 CD-ROM support includes audio, ISO 9660/High Sierra, CD-ROM/XA, and Kodak Photo CD-compatibility for those drives that support these standards.

Note: You also can obtain a list of the CD-ROM drives that are supported by your version of OS/2 by performing the following:
#Double-click on the OS/2 System folder. The folder opens displaying a number of additional folders.
#Double-click on the System Setup folder. The folder opens displaying a number of objects.
#Double click on the Selective Install object. The System Configuration pop-up window appears.
#Use your mouse to put a checkmark in the CD-ROM Device Support box.
#Click on OK. A pop-up window appears showing the list of supported CD-ROM drives Use the scroll arrows to see if your CD-ROM drive is supported.

'''Q. Why don't I receive any output when I send a print job to the printer over the LAN, even though the job gets spooled? This is a job that will print on a local printer.'''

A. To resolve the problem, change the CONFIG.SYS file on the server as follows:
 PRINT MONBUFSIZE=134,134,134
to
 PRINT MONBUFSIZE=2048,134,134
This change will set the parallel-port device driver buffersize. Each number corresponds to the buffer size for LPT1, LPT2, or LPT3, respectively. The minimum value that you can specify is 134 bytes; the maximum value is 2048 bytes. Changing these valu es will increase the size of the parallel-port device-driver buffers. This, in turn, increases the performance of data transfer to devices that are connected to the parallel ports.

'''Q. Why does a 16-bit OS/2 application run in an OS/2 full-screen session, but fail in an OS/2 window session?'''

A. An OS/2 full-screen session is a native OS/2 environment, whereas the OS/2 window screen session is a PM environment. That is, the OS/2 window session actually has the application running as a child process under the OS/2 Presentation Manager application (which is considered the parent process).

The failure is usually an access violation (TRAP 0005 or SYS3175) in the DOSCALL.DLL, PMWIN.DLL, or PMGRE.DLL module. This can happen during the conversion of 16-bit API requests into 32-bit API requests or vice-versa This conversion process is known as thunking, or more specifically 16-to-32-bit thunk or 32-to-16-bit thunk. Because OS/2 2.0 and higher run in 32-bit environments, thunking occurs, to some degree, for 32-bit applications.

Memory is overwritten at a point that is decimal 2608 bytes (0a30 hex) from the top the applications stack. Specifically, if the bottom of the stack is at hex 00b0 and the top of the stack is at hex 1060 then memory at the location of 10b0 hex minus 0a30 hex is overwritten (0a30 hex). This can cause a problem if the stack size is smaller than decimal 4096 bytes, because the area that is overwritten can fall into the data variable area of the application.

To avoid this, application developers should use a module.DEF file that contains a minimum Stack size of 4096 bytes or larger, along with a Heap size of 4096 bytes. This overrides the language compiler/linker default Stack and Heap sizes.

With the OS/2 Toolkit, you can use the following work-a-round. Run the EXEHDR utility to change the Stacksize and Heapsize of the application's exetable module. As an illustration:

At the OS/2 command prompt, type:
 EXEHDR myapp.exe
(where myapp.exe is the name of the application's exectable module.)

The Stack size will appear; for example:
 Extra stack allocation:    0964 bytes
Increase your Stacksize and Heapsize to a minimum of hex 2000 bytes larger than required by your application's executable module. For example, use the following command to set a Stacksize of decimal 6500 bytes and a Heapsize of decimal 4096 bytes:
 EXEHDR /STACK:6500 /HEAP:4096 myapp.exe

'''Q. When I use the IBM C Set++ Compiler, does the appropriate event handling function get called if my class contains a pointer to an IHandler? In other words, if I have the following window class and a command handler:'''
<code>
    class MyWindow : public IDialogWindow {
              IHandler *p;
        public:
            MyWindow(IHandler *x) : p(x) {
        //...
       }
       //...
    };
    class MyCmdHandler  : public ICommandHandler  {
       //...
        Boolean command (ICmdEvents&);
     };

     void main() {
             MyCmdHandler mycmdhandler;
             MyWindow mywindow(mycmdhandler);
            //...
     }
</code>
will MyCmdHandler::command() get called for WM_COMMAND?

A. Your handler will work just fine. The message dispatching code calls the handler's dispatch HandlerEvent function. In your case, this will be the implementation you inherit from ICommandHandler. This function will call this >command(), which you've reimplemented and this will invoke your command() function. This is the justification for C++ virtual functions.

'''Q. When using the C Set ++ Compiler, I can't set any form of breakpoints in source view. I can set them in disassembly view. Why?'''

A. You must set the breakpoints by double-clicking in the PREFIX area of an EXECUTABLE in the Program View windows. If the statement is not executable (usually it will be shown in a different color), you won't be able to set the breakpoint there.

Note: Be aware that most people who have this problem are not using the right linker. This can cause the debugger to lose track of which lines of source code relate to the actual code that is running.

{{IBM-Reprint}}
[[Category:Developer Connection News]]