rommel@lan.informatik.tu-muenchen.dbp.de (Kai-Uwe Rommel) (05/31/90)
Some time ago I asked for information about controlling spawned child applications under Windows. Spawning applications itself is rather easy if you read the discussion about this topic here last year. What I needed was a "handle" to the child program and a way of at least asking if it still exists. This is an odd situation. MS-DOS has only synchronous spawn (clear) but Windows has only asynchronous spawn (well, better than having only the other type) but nothing like wait() or so. In a program I need to call an external editor (with a text file as an argument) and to read the text file in back after the editor exited WITHOUT user interaction. That means I have to be informed of the childs exit. I did not get any response, this may either be of no interest to others :-( or nothing has done this and some may be interested in a result :-). I played for a while and finally found a way. Well, it uses one undocumented feature but even spawning under Windows itself is not officially documented by Microsoft in the SDK documentation. 1. When you spawn a child program with INT 21 using the Microsoft sample code posted here during the spawn-discussion, you get the instance handle of the child program back in AX from the INT 21. For old applications called using a PIF file (spawn with "PROG.PIF" as executable name) you get the instance handle of WINOLDAP.MOD but this works reliable only if not more than one old app is called. 2. You can test if the application still exists using the GetModuleFilename() call with the handle from 1. The call returns the length of the pathname of the program copied to your buffer or zero, if it does not longer exist. Unexpectedly, the GetModuleUsage() call returns one even if the instance handle given as argument is invalid Now I test for existence of the child app using GetModuleFilename() in a timer callback function after spawning the child and it seems to work reliable even if I call an old application like MicroEMACS as the editor via a PIF file. I HOPE that Windows 3.0 provides an API extension for control of child programs and spawning, the use of INT 21 is SO ugly .... Kai Uwe Rommel Munich rommel@lan.informatik.tu-muenchen.dbp.de
news@athena.mit.edu (News system) (06/04/90)
The documented way to control spawned windows is with the DDE interface. There is a section in the SDK Extensions manual that discusses using DDE with DOS standard apps. This allows one to start, stop, pass keyboard input, and copy screens of the DOS application all under program control. To simply be able know when an application terminates would not require full DDE implementation. There are two catches which are not documented. It only works in Windows 286 (W/386 uses virtual machines for DOS apps so Windows "losses control", in the words of a MS support person) and many applications poll the keyboard when doing lengthy operations such as file saving (looking for ESC) and Windows will lose strings that were meant to be read at the applications normal prompt. In other words, Windows can tell when an app terminates but not when it is waiting for input. Final caveat is that it is probable that this will not be supported in Windows 3.0. P.S. could someone send me a summary of the spawning dicusses from last year? Chris Cimino, MD Internet: ccimino@hstbme.mit.edu