aaron@backyard.bae.bellcore.com (Aaron Akman) (04/11/91)
Can a Windows application invoke a non-windows application with an
``execv'' type of function? Say the non-windows application just does
regular printf's or no screen output at all. How would it work?
Would it appear in its own window? If it looked like:
main()
{
printf("Hello, world\n");
}
would the window pop-up and then disappear again quickly? Is there a
more elegant way for the windows app and the non-windows app to
communicate other than file I/O?
___________________________
Aaron Akman
aaron@backyard.bellcore.com
908-699-8019jeff@cdp.UUCP (04/11/91)
You can use WinExec(), which is closer to system() than to execv(). Even for a short program, Windows will switch to the full screen (or a window, if you're using a PIF file and have specified windowed mode). File I/O is the easiest way to communicate, but there are definitely better ways, e.g., a shared block of memory. By the way, note that WinExec() is asynchronous, and will probably return before the requested program has completed. Jeff Dean jeff@cdp.igc.org uunet!pyramid!cdp!jeff
aaron@backyard.bae.bellcore.com (Aaron Akman) (04/11/91)
In article <1266500005@cdp>, jeff@cdp.UUCP writes: > > You can use WinExec(), which is closer to system() than to execv(). > Even for a short program, Windows will switch to the full screen > (or a window, if you're using a PIF file and have specified > windowed mode). File I/O is the easiest way to communicate, but > there are definitely better ways, e.g., a shared block of memory. > > By the way, note that WinExec() is asynchronous, and will probably > return before the requested program has completed. > > Jeff Dean > jeff@cdp.igc.org > uunet!pyramid!cdp!jeff If the WinExec()'ed program is a regular DOS program (with a PIF to make it popup in a window) that does modem stuff, will everything else stop until it finishes? Do regular DOS apps ever get multitasked? Off int 28h, or something? ___________________________ Aaron Akman aaron@backyard.bellcore.com 908-699-8019
jeff@cdp.UUCP (04/12/91)
A WinExec'ed DOS progam will run in the background if the Background option is enabled (either in the PIF editor, or by setting it from the system menu). I believe this background operation only works in enhanced mode. This works properly even if the background program is doing telecommunications, although at high speeds, Windows may not be able to keep up (causing characters to be dropped). Jeff Dean jeff@cdp.igc.org uunet!pyramid!cdp!jeff
ergo@netcom.COM (Isaac Rabinovitch) (04/13/91)
In <1266500005@cdp> jeff@cdp.UUCP writes: >By the way, note that WinExec() is asynchronous, and will probably >return before the requested program has completed. > Jeff Dean Which reminds me of a problem that's been bothering me since I first started playing with windows: when you WinExec() or LoadModule() a program, how to you find out the handle of the window you've just created? Here's another one: what's the practical difference between WinExec() and LoadModule(). Please don't say "WinExec is an alternative to LoadModule() and vice versa" -- only lazy techwriters are allowed to do things like that! -- ergo@netcom.com Isaac Rabinovitch netcom!ergo@apple.com Silicon Valley, CA {apple,amdahl,claris}!netcom!ergo All work and no play makes Jack a dull boy. -- Jack
sidney@borland.com (Sidney Markowitz) (04/13/91)
ergo@netcom.COM (Isaac Rabinovitch) writes: >Which reminds me of a problem that's been bothering me since I first >started playing with windows: when you WinExec() or LoadModule() a >program, how to you find out the handle of the window you've just >created? > >Here's another one: what's the practical difference between WinExec() >and LoadModule(). Please don't say "WinExec is an alternative to >LoadModule() and vice versa" -- only lazy techwriters are allowed to >do things like that! LoadModule() returns a handle to the instance of the module that it creates, lets you specify a couple of things inthe second parameter, and can only be used to run a Windows app. WinExec() returns a value that is not documented, other than being greater than 31 if successful, doesn't let you specify some things that LoadModule() does, and can be used to run both Windows and DOS apps. If you use LoadModule(), you can look at all the windows (using GetWindow(GW_HWNDNEXT)) and for each one call GetWindowWord(hWnd,GWW_HINSTANCE) to see if it is the same as the return value from LoadModule(). I'd be interested in hearing if anyone has a less kludy way of doing it. -- sidney markowitz <sidney@borland.com>
jeff@cdp.UUCP (04/14/91)
WinExec() returns the same value as LoadModule(). LoadModule is "lower level" than WinExec (WinExec actually invokes LoadModule). Jeff Dean jeff@cdp.igc.org uunet!pyramid!cdp!jeff
bonneau@hyper.hyper.com (Paul Bonneau) (04/15/91)
In article <1991Apr12.211658.28611@netcom.COM> ergo@netcom.COM (Isaac Rabinovitch) writes: > >Which reminds me of a problem that's been bothering me since I first >started playing with windows: when you WinExec() or LoadModule() a >program, how to you find out the handle of the window you've just >created? > You can do this with either: EnumWindows() for (hwnd = GetWindow(hwndNull, GW_HWNDFIRST); IsWindow(hwnd); hwnd = GetWindow(hwnd, GW_HWNDNEXT)) Either way, the idea is to compare the string returned from GetClassName() with the name of the class of the main window in the new program. cheers - Paul Bonneau.
bonneau@hyper.hyper.com (Paul Bonneau) (04/15/91)
In article <1991Apr13.010556.25866@borland.com> sidney@borland.com (Sidney Markowitz) writes: > >LoadModule() returns a handle to the instance of the module that it >creates, lets you specify a couple of things inthe second parameter, >and can only be used to run a Windows app. WinExec() returns a value >that is not documented, other than being greater than 31 if ^^^^^^^^^^^^^^^^^^^^^^ >successful, doesn't let you specify some things that LoadModule() >does, and can be used to run both Windows and DOS apps. > The return value from WinExec() IS documented in the SDK book "Reference - Volume 1", on page 4-459 under "Return Value" for WinExec(). cheers - Paul Bonneau.
sidney@borland.com (Sidney Markowitz) (04/15/91)
bonneau@hyper.UUCP (Paul Bonneau,,) writes: >sidney@borland.com (Sidney Markowitz) writes: >>WinExec() returns a value >>that is not documented, other than being greater than 31 if successful > ^^^^^^^^^^^^^^^^^^^^^^ >The return value from WinExec() IS documented in the SDK book >"Reference - Volume 1", on page 4-459 under "Return Value" for >WinExec(). The SDK Ref only documents the error codes, which are less than 32. I meant to say that the return value of a successful call is not documented other than being greater than 32. That makes it sound suspiciously like the "module instance handle" returned by LoadModule, and jeff@cdp claimed that they are the same, but the doc doesn't say so. I suppose that Jeff's claim that WinExec just passes back the return value of LoadModule would be easy to check with a debugger, but it still leaves open the question of what it does with a non-Windows app (which LoadModule won't take) and what the return value is for that. Does anyone know? -- sidney markowitz <sidney@borland.com>
risto@tuura.UUCP (Risto Lankinen) (04/15/91)
ergo@netcom.COM (Isaac Rabinovitch) writes: >In <1266500005@cdp> jeff@cdp.UUCP writes: >>By the way, note that WinExec() is asynchronous, and will probably >>return before the requested program has completed. >Which reminds me of a problem that's been bothering me since I first >started playing with windows: when you WinExec() or LoadModule() a >program, how to you find out the handle of the window you've just >created? Hi! You have no knowledge, of whether you actually have had a window created via WinExec()/LoadModule() call - or whether you have had more than one window created for that matter. You have to make assumptions about the program being executed. Supposing it makes at least one 'standard' window, you should use LoadModule() to get the instance handle of the executed application in return. Then search thru all of the windows with a suitably parametrized GetWindow() loop, comparing each window's instance (with GetWindowWord(...,GWW_HINSTANCE); ) to the value you got from the LoadModule() . The one{s} that match is {are} what you want. Terveisin: Risto Lankinen -- Risto Lankinen / product specialist *************************************** Nokia Data Systems, Technology Dept * 2 2 * THIS SPACE INTENTIONALLY LEFT BLANK * 2 -1 is PRIME! Now working on 2 +1 * replies: risto@yj.data.nokia.fi ***************************************
jeff@cdp.UUCP (04/16/91)
>so. I suppose that Jeff's claim that WinExec just passes back the >return value of LoadModule would be easy to check with a debugger, but >it still leaves open the question of what it does with a non-Windows >app (which LoadModule won't take) and what the return value is for >that. Does anyone know? Sidney, Yes, you can easily verify that WinExec() returns the value from LoadModule(). With a little more time spent in the debugger, you can learn how WinExec() handles a DOS application: WinExec() calls LoadModule() twice for a DOS application. The first invocation is for the "grabber" (see the SYSTEM.INI file). The second invocation is for WINOA???.MOD (WINOA386.MOD for enhanced mode). [I've only done this "debugging" in enhanced mode.] The process/task running WINOA seems to be the one that "controls" the DOS application. Jeff Dean jeff@cdp.igc.org uunet!pyramid!cdp!jeff