Microsoft KB Archive/67666

INF: Using WinExec with Non-Windows Applications ID Number: Q67666

3.00 WINDOWS

Summary: The WinExec function allows a Windows application to initiate the execution of another Windows application or of an MS-DOS application. This article discusses the value returned from WinExec, how resources are shared between the processes, and the effect of the nCmdShow parameter.

More Information:

WinExec is called to start another task. This may result in the execution of a Windows application or of an MS-DOS (non-Windows) application. The return value from WinExec specifies whether the function was successful.

However, when WinExec is called to execute an MS-DOS application, “success” indicates that a Windows application (WINOLDAP) has been loaded into memory and has started execution. A “success” return value does not mean anything more.

WINOLDAP creates a window for the MS-DOS application and loads the application into memory. Control is then transferred to the MS-DOS application. Sharing of system resources depends on the mode in which Windows is running. If it is necessary for the MS-DOS application to have completed its processing before the Windows application can continue, the dependent code cannot be placed immediately following the WinExec call. Because of the way that the window is created for the MS-DOS application, it is possible that WINOLDAP will yield and that the Windows application will get processor time before the MS-DOS application has even begun execution. For more information on techniques on how to determine that the MS-DOS application has accomplished its task, query on the following keywords:

prod(winsdk) and tandem and finished Once WINOLDAP has transferred control to the MS-DOS application, system resources are allocated, depending upon the Windows mode. In real and standard modes, when the MS-DOS application is running, Windows activity stops. The MS-DOS application is given exclusive control of the processor for this time.

In enhanced mode, resource sharing depends upon settings in the program information file (PIF) that corresponds to the MS-DOS application.


 * If both the Exclusive Execution and the Full Screen options are selected, the MS-DOS application is given exclusive control of the processor until it completes execution.
 * If either the Exclusive Execution or the Full Screen option is not selected, Windows will preempt the MS-DOS application and share the processor with it.

Depending on what mode Windows is running in, the nCmdShow parameter is treated differently for old applications. Because real and standard mode Windows execute an old application only in full screen mode, the nCmdShow parameter will have no impact on the application’s appearance. In these modes, the nCmdShow should be set to SW_SHOW, SW_SHOWNORMAL, or SW_NORMAL. Any other choice will result in WINOLDAP, assuming the user wanted to load the application as an ICON.

If the old application is executed in 386 enhanced mode and it has “Windowed” selected as the Display Usage in its .PIF file, the nCmdShow parameter will have a direct impact on its window’s appearance. Old applications that will run to completion without user interaction can use the SW_HIDE option. This will run the application with the least impact on the Windows display.

Under Windows, the spawn function provided by the C-language run-time libraries will not work as expected.

If it is necessary for a MS-DOS application to communicate with Windows, then contact the SoftBridge company, which will provide additional information on its product offerings. Contact information is listed on page 107 of the “Windows Shopping” book, which is supplied with the Windows version 3.0 retail product.