Tips 'N Techniques - Nov 1993

Use the following tips to increase your productivity!

Device Driver Tips

 * To access a GDT selector during Init, start a timer handler that will be called within 32ms at ring 0; then perform the access.
 * If you need to post a 32-bit shared even semaphore at interrupt time, which normally can't be done, allocate and arm a context hook. This hook will be called at task time and therefore will be able to post the semaphore.

Performance

 * Tip:Reduce your icon sizes and increase system performance.


 * Technique:Attaching icons to desktop objects (abstract objects for WPS programmers) can increase the size of the OS2.INI file. This can potentially effect system performance. Large icons shipped with software cascades this effect to users.
 * Icons are stored as bitmap arrays. This allows for different display types and resolutions. Unfortunately, the more formats stored, the larger they get. But many icons don't require many colors or resolution. If you edit them with the icon editor and save only the Independent VGA format, they will be less than 1K. If this format isn't present, just add it from the menu. The existing format will be rendered into the new format. And, the VGA is a pretty good lowest-common-display type.
 * The opposite extreme can be seen by saving an icon with all possible formats. The resulting file is around 17K. With so many desktop objects, you can see how we can all benefit by smaller icons.

KwikINF Tips and Techniques
Like any tool, there are good and bad ways to use them. Here are some of my favorite tips for getting the best use and performance out of KwikINF.

Don't use full-screen monitors if you don't need them. It wastes memory and creates a keyboard monitor for every full screen session you start (up to the maximum set in the configuration menu.

Keep books open if you intend to keep accessing them. It can take a long time to open a book. If you're writing new code, you'll likely want frequent access to certain online references. If you leave the book open (minimized), you won't have to wait so long each time you press Alt+Q.

Trim down your index files! If you create an index file for your own online reference, then take advantage of the wildcard character (*) supported in index files. Every single entry in an index file has to be allocated, added to an index table in memory, and searched by KwikINF. If we didn't use Win* to specify the PM reference in the toolkit index file, there would be a LOT of unnecessary index entries for every WinXXX API in our index table.

Don't restrict KwikINF to your editor. There are other ways to benefit from this tool. I've often typed an API on a Windowed Command Prompt so I could press Alt+Q and get help on it. And one of my favorite tricks is to get help while I'm reading E-mail or a public forum. I can answer a technical question with the press of a key.

MMPM/2 Tips and Techniques

 * Tip: Improve overall performance in MMPM/2 applications.


 * Technique 1:WRITE MULTITHREADED APPLICATIONS! This is the most important tip and cannot be stressed enough! OS/2 is a very powerful operating system and provides its programmers with the ability to execute more than one activity (thread) at a time. This is not automatic, however; it must be programmed into applications. The benefits gained from multithreaded applications are tremendous. This is especially true when it comes to Presentation Manager (PM) applications. A PM application should never tie up its main message procedure's thread for very long. If it does, users will experience the OS/2 timer icon, and be unable to manipulate the application (or other applications) for a period of time. This also holds when programming MultiMedia Presentation Manager/2 (MMPM/2) applications. Time-consuming Media Control Interface calls should not be made from within a PM application's main message procedure's thread. Instead, a worker thread should be created to make the MCI call. The most time consuming calls include MCI_OPEN, MCI_CUT, MCI_COPY, MCI_PASTE, MCI_SAVE, and sometimes MCI_LOAD (this depends on the device and/or the file size).


 * Technique 2:Use the MMPM/2 pre-roll capability provided through the MCI_CUE message. When an application will have a time delay between an MCI_LOAD and an MCI_PLAY of a file (like a Wave Player application: where the user opens a file [MCI_LOAD], then presses a butt on to start playing the file [MCI_PLAY]) the application should make an MCI_CUE call. This message will pre-roll the data (pre-fill the play buffers) and allow the MCI_PLAY to start immediately. Without the MCI_CUE message, an MCI_PLAY will take longer as it will automatically take the time to perform an MCI_CUE.
 * Note: The MCI_CUE will have no effect if the MCI_PLAY uses the MCI_FROM flag. The MCI_FROM will change the start position of a file and thus invalidate the buffers that were pre-filled. If a file is to be played FROM a particular position, one should first MCI_SEEK to the position, issue the MCI_CUE, and then finally, when appropriate, issue the MCI_PLAY message.


 * Technique 3:Don't close a device unless necessary. Many applications MCI_OPEN a device, MCI_LOAD a file, MCI_PLAY the file, and then MCI_CLOSE the device they are using. This is fine, however, some of these applications then turn around and re-issue MCI_OPEN the same device, MCI_LOAD another file, MCI_PLAY, and then MCI_CLOSE again. This is very wasteful. On each open, a device must be initialized, resource must be allocated, and so on. It is much more efficient (and desirable) to leave the device open and simply do another MCI_LOAD and then another MCI_PLAY. The basic rule of thumb to follow is: Re-open a device as little as possible.


 * Technique 4:Open and close devices that will be needed prior to using them. The most time consuming MCI message is the MCI_OPEN message. Opening a device takes time due to the amount of work that must be accomplished (initializing the device, allocating device resource, making the appropriate connections and perhaps, even loading a file). The MCI_OPEN takes a bit longer than usual when a device is opened for the first time, because the associated dynamic link libraries (DLLs) for that device must be loaded. Pre-opening and closing the particular device(s) that will/may be used will load the needed DLLs. These DLLs will remain loaded (even after an MCI_CLOSE), as long as the application is still running. Subsequent MCI_OPEN calls will occur quicker, because the DLLs are already loaded. For example, a digital video application could, on its initialization, create a thread to open and then close the digital video devices it might be using. When the user determines which device will be used (perhaps by selecting a particular video file) the device's DLLs will have already been loaded, and thus the open will occur quicker.
 * Note: When MMPM/2's system sounds are installed, part of the audio subsystem will have already been loaded at system boot time, thus there may not be a need to open and close the audio device prior to using it in an application.