dale@mks.com (Dale Gass) (05/03/91)
I am looking for information on how to launch Windows 3.0 Applications from non-windows application running in a Window. I can not find any obvious method of doing this. It seems that WinExec() is the key to lauching Windows apps from other apps, but this call is only available from within Windows applications. It seems that Windows is the only entity "smart" enough to be able to successfully load Windows .EXE's. Having a Windows application as a "wrapper" for my non-windows application would be acceptable. Is there any way for a non-windows application who is a child of Windows application to communicate with it's parent, to request launching of another Windows app? It seems to me that with older versions of Windows, one could start Windows programs from within the DOS box. Am I mistaken? (If this was the case, they must have taken over the DOS exec call...) (Starting another copy of windows from inside a Window is not an acceptable solution.) Microsoft Technical support was unable to provide any answers. Any advice would be appreciated. Thanks, -dale@mks.com uunet!watmath!mks!dale
ed@odi.com (Ed Schwalenberg) (05/05/91)
Dale Gass asks, "I am looking for information on how to launch Windows 3.0 Applications from non-windows application running in a Window." This is really hard, because in 386Enhanced mode the DOS app and the Windows world are in separate virtual machines; the only context they have in common is the underlying DOS. The basic idea is to use a TSR that talks to both the DOS app and a Windows "wrapper" app that does the WinExec for you. Create a TSR that gets loaded before Windows is started. Its services will be available to both DOS apps and Windows apps. When Windows is started, your wrapper program can call the TSR with an INT 2F, giving it the address of some GlobalDOSAlloc'ed memory which will be used to pass information back and forth between the TSR and protected-mode Windows. While processing this INT 2F, you issue one of your own, with AX=1683h, which will return in BX the magic number of the Windows Virtual Machine, which is currently 1 but may change. The DOS application issues an INT 2F, passing the name of the desired application to the TSR. The TSR copies the information into a private data buffer in the TSR's address space, NOT to the GlobalDOSAlloc'ed memory (which only exists in the Windows virtual machine). Now for the hard part. You need to call back to Windows when the Windows VM is scheduled. To do that, use INT 2F, AX=1685h, BX=Windows VM number which you saved from the initialization step, CX=flags, DS:SI = priority boost and ES:DI = CS:IP of a procedure to call. When the Windows VM is scheduled, your procedure will be called. That procedure can copy the name of the application into the GlobalDOSAlloc'ed memory, issue an INT 2F to the windows wrapper program, and IRET. The windows wrapper program can use the data in the GlobalDOSAlloc'ed memory to WinExec the desired program. Full documentation on these INT 2F functions are in Appendix D of the Virtual Device Adaptation Guide, which is part of the DDK. This is all based on my understanding of the documentation, not on real- life experience. I don't know what steps would vary if you were running Windows in standard or real mode. In short, I'm not an expert nor do I offer warranties.
Randy_Humes@f117.n151.z1.fidonet.org (Randy Humes) (05/09/91)
There is a Windows product called Bridge from a company called SoftBridge that you may be able to adapt to solve your problem. It is a winapp that you can confige to launch DOS or winapps from a personnalized window. Sorry, I have no number but it was listed in the Windows Shoppers Guide.