>Claude,
>
>ShellExecute can run both internal and external DOS commands (check the samples on my site). The visibility of the spawned window is controlled by the last argument to the function call.
>
>>Added benefit of CreateProcess is that it'll even run DOS commands invisibly.

The real issue with ShellExecute() per se is the inability to conveniently control the synchronous/asynchronous execution behavior of the processes, and to poll the state and terminal result code, which is why I use CreateProcess() in API_APPRUN. Some day, I'll get off my duff, document the new behaviors and release the newest version of API_APPRUN, which I've been using for about 8 months now - I added support for ShellExecuteEx(), permitting a LaunchDocAndWait() method; I hesitate because of problems that people using some WinApps like Word will have, since Word returns a pseudo-ProcessID that can't be used to track termination of a particular instance of Word or not fail to detect the closing of one document if another is opened. What I'm willing to support for myself is not nedessarily the same thing as what I can release, for fear of being flamed when the consequences of using certain types of apps are not clearly understood, and are reported angrily as bugs.

Another neat new behavior, that I also hesitate to release, is the ability to construct a PIF for a DOS app indirectly, to allow control of the VDM created when a new DOS App or Win16 app is launched. It's too easy to have the developer guess wrong about memory or Windows GUI behavior, and end up with a large, sticky blob of goop on the screen where an app should have been.

Until the time I'm comfortable enough to release the successor to API_APPRUN, either Wscript.Shell's Run, or API_APPRUN, offer the best option for running an app; ShellExecute() is clearly preferable when launching an app indirectly against a doc with a particular action such as PRINT or PRINTTO.