DDK Q's and A's - Nov 1993
- Question 1
- My Toolkit will not run properly. I get a message that the file PMREF cannot be found. How do I solve this problem?
- References to PMREF should be changed to the name PMFUN. This seems to fix the problem. Also, C/Set&Toolkit&WorkFrame must be installed in the following order: Toolkit, WorkFrame, C Set/2. If they are not, WorkfFame will not be aware of C Set/2 and some of the function will not be available.
- If you get missing libraries, such as dde4XXXX, you need to go back and install the migration part of the compiler.
- Question 2
- I get an Error Unresolved External 2029 message when trying to link a program. Why?
- The following statements need to be present and correct in the OS/2 CONFIG.SYS file:
- The LIBPATH line must include: x:\TOOLKT20\DLL;x:\IBMC\DLL;x:\IBMWF\DLL; (x: = drive letter)
- The SET PATH line must include: x:\TOOLKT20\OS2BIN;x:\IBMC\BIN;x:\IBMWF\BIN;
- The SET DPATH line must include: x:\IBMC\LOCALE;x:\IBMC\HELP;x:TOOLKT20\BOOK;
- The SET HELP line must include: x:\TOOLKT20\OS2HELP;x:\IBMC\HELP;x:\IBMWF\HELP;
- The following lines should be at the end of the CONFIG.SYS:
SET PROGREF20=GUIREF20.INF SET PMREF=PMFUN.INF+PMGPI.INF+PMHOK.INF+PMMSG.INF+PMREL.INF+PMWIN.INF+PMWKP.INF SET HELPNDX=EPMKWHLP.NDX+DDE4.NDX SET IPFC=x:\TOOLKT20\IPFC; SET INCLUDE=x:\TOOLKT20\C\OS2H;x:\TOOLKT20\ASM\OS2INC;x:\IBMC\INCLUDE SET LIB=x:\TOOLKT20\OS2LIB;x:\IBMC\LIB
- Question 3
- I notice that the OS/2 2.0 toolkit documentation, specifically the manual OS/2 2.0 Physical Device Driver Reference, was not changed to reflect the code change to touch display support. Is there a reason for this?
- The mouse IDC, Process_Absolute, has been changed in OS/2 2.0 because a defect was raised by the IBM Touch Display support added to 2.0. The change was to remove the function where the MOUSE.SYS device driver would check the movement of the mouse pointer against the button mask that was passed in and change that mask if there was a discrepancy. This was deemed in error since there are occasions where the device-dependent driver may want to pass these bogus values up the chain to running applications.
- The OS/2 2.0 Toolkit documentation, specifically the manual OS/2 2.0 Physical Device Driver Reference, was not changed to reflect the code change. In the Physical Mouse Device Driver Reverence (in the Mouse IDC section), there is a reference to the "EVENT" field that should be changed.
- Remove/ignore the following sentence:
- The event field should never indicate that motion was associated with the event. MOUSE$ determines if motion occurs.
- Question 4
- I created an application program, but the CD drive doesn't respond as it does with the Compact Disc program. What am I doing wrong?
- Check proper use of APIs and verify sufficient stack is used when creating a second thread, as follows:
- Check that you are using commands with the same alias that was used on the "open" if using the string interface, or the same DeviceID that was returned on the MCI_OPEN command if using the procedural interface.
- If creating a second thread, make sure that sufficient stack is allocated. The IOCTL router or CD drive driver sometimes acts peculiar if low stack is used on a secondary thread. We recommend 64KB, but you must have at least 16KB.
- If using C Set/2, use _beginthread instead of DosCreateThread. See the C Set/2 user's manual for more details.
- Question 5
- I am getting a general protection fault error when I try to run an FSCANF statement in a DLL. The DLL is being called from two different programs in two different sessions. What is happening?
- The FSCANF and other like functions are called critical functions. They cannot be run in a DLL because they lack SEMAPHORES. This means that when an FSCANF runs, it grabs hold of everything and doesn't allow another process the use of FSCANF. The solution is to use exception handling or DosRead. The DosRead functions have SEMAPHORES built in, and therefore allow multiple processes to simultaneously access them.
- Question 6
- My system hangs intermittently (shell hang; not kernel) when running certain PM Applications that utilize DosKillThread() or DosKillProcess(). What is the reason for this?
- The problem is that any thread that makes PMWIN calls may own/control certain PMWIN controls, such as semaphores, and may be currently in the middle of updating global PMWIN structures. Both DosKillThread() and DosKillProcess() will force the thread(s) of the process to die upon immediately exiting from the Kernel. However, PMWIN runs at rings 3 and 2, so their operations are not completely within the kernel. This may cause a user thread to die while in the middle of updating a PMWIN structure.
- The only resolution, until PMWIN becomes 32-bit, is for the developer to use some form of IPC in place of DosKillxx() calls (such as, Semaphores, Queues, Shared Memory, or Presentation Manager Messages.)
Reprint Courtesy of International Business Machines Corporation, © International Business Machines Corporation