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.