| All Forums |
Register |
Login |
Search |
Subscriptions |
My Profile |
Inbox |
| Tool Warehouse |
FAQs |
Resources |
Help |
Member List |
Address Book |
Logout |
|
|
Starting Win32 apps from an Interix daemon
|
Logged in as: Guest |
| Users viewing this topic: none |
|
Login  |
|
|
 Starting Win32 apps from an Interix daemon - Aug. 18, '05, 7:00:48 AM
|
|
|
hp
Posts: 25
Joined: Aug. 5, '04,
Status: offline
|
Is there a way to start a Win32 application that opens up a window from an Interix daemon running under local Administrators account?
The application gets started and runs in an automated mode. It reads some files, processes them and writes some output files. The bad thing is that this application provides also an interactive mode and always tries to open it's window.
When I try to start this application from an Interix daemon, the application hangs or crashes.
Does anybody know why it crashes and what I can do there?
|
|
|
|
|
RE: Starting Win32 apps from an Interix daemon - Aug. 18, '05, 9:25:58 AM
|
|
|
Rodney
Posts: 3142
Joined: Jul. 9, '02,
From: /Tools lab
Status: online
|
Each user does get a Window Station. So the GUI part will start, but you'll never be
able to see it or interact with it because the station is not visible (xref the man
page for the utility (wvisible). This will not be the part causing a crash.
The likely reason for the crash is how Win32 handles stdin and stdout for a program.
From a Unix (Interix) daemon it's very likely stin/stdout are file descriptors to sockets.
In the Win32 world a file handle is not a file handle. So the program crashes.
You need to give the program some other stdin/stdout. Typically this can be done
by redirecting /dev/null as stdin/out (or some other disk file). As another xref you
should give the manual page for cat32 a read.
Also remember that your Win32 program, if you are providing arguements, will expect paths
to be in Win32 syntax. So double-quote anything with a backslash in it so that the shell
won't do an interpretation. You can convert from Interix/Unix to Win32 paths with the
utility unixpath2win.
e.g.
/dev/fs/C/WINDOWS/system32/dog.exe /p "C:\temp" < /dev/null > /dev/null
|
|
|
|
|
RE: Starting Win32 apps from an Interix daemon - Aug. 22, '05, 10:49:59 AM
|
|
|
hp
Posts: 25
Joined: Aug. 5, '04,
Status: offline
|
Rodney,
the problem is that the Win32 application never receives any messages.
It hangs in the GetMessage() function and simply receives no message - no WM_CREATE, no WM_PAINT and so on.
To get a test program, I used the VisualStudios Project Wizard and created a Win32 Project which is a Window with a simple menu. Then I added a "Sleep(10000);" and a "PostQuitMessage(0);" to the WM_PAINT section and some fprintf's to write to a trace file everywhere.
When I start the program on the local Windows host, the Window pops up and closes after 10 seconds. The trace file contains all the expected lines.
When I start the program from a rlogin session from another host OR from the Interix daemon (which seems to produce exactly the same behaviour), the program runs up to the GetMessage() function and waits there forever.
The problem is not the creation of the main window, it's the missing messages.
Is this an expected behaviour?
Can I somehow work around it? Can I create a Windows station on my own and attach the Win32 application to it?
Thanks a lot for your answer!
|
|
|
|
|
RE: Starting Win32 apps from an Interix daemon - Aug. 22, '05, 11:28:05 AM
|
|
|
Rodney
Posts: 3142
Joined: Jul. 9, '02,
From: /Tools lab
Status: online
|
> program runs up to the GetMessage() function and waits there forever.
ah, ha-ha, of course. It's waiting for a response in the GUI. Likely for a click on the "Okay button".
I expect that the program didn't find something (like a DLL) and is complaining about it in its
standard manner. It's most likely that in PATH (the environmental variable) a path is missing.
The path "/dev/fs/C/WINDOWS/system32/wbem" is often a key one for DLL's; it might be something else
like a resource. On the other hand if it's expecting input via the GUI you're out of luck.
Try starting the app from a CMD.EXE. If it works, then try adding paths from the CMD.EXE "PATH"
to the Interix "PATH", and then retry running it.
|
|
|
|
|
RE: Starting Win32 apps from an Interix daemon - Aug. 23, '05, 9:16:47 AM
|
|
|
hp
Posts: 25
Joined: Aug. 5, '04,
Status: offline
|
To be sure if it waits for some input, e.g. the click on the OK button of a "Can't find DLL"-MessagBox, I wrote a little function that writes the handles and titles of all windows to my trace file. My test app calls this function immediately before GetMessage();
I tested it on the local host - it really writes all Windows, including a MessageBox and even it's OK button (which is a Window on it's own, too) to the trace file.
On the remote host, it writes only two windows to the trace file - the desktop and the main window of my test app.
This means I'm now sure that it doesn't wait for some input. It has to be something different.
Can it be a permission problem? Does the user have to have special permissions to start a working 'virtual' desktop?
Or is there anything that has to be set up or started manually to make these 'virtual' desktops work?
Is there any useful documentation about it?
I'd appreciate every bit of information that helps me!
Thank you!
|
|
|
|
|
RE: Starting Win32 apps from an Interix daemon - Aug. 23, '05, 10:38:39 AM
|
|
|
Rodney
Posts: 3142
Joined: Jul. 9, '02,
From: /Tools lab
Status: online
|
> To be sure if it waits for some input, e.g. the click on the OK button of a "Can't find DLL"-MessagBox, I wrote a little
> function that writes the handles and titles of all windows to my trace file. My test app calls this function immediately
> before GetMessage();
Cool.
> Can it be a permission problem? Does the user have to have special permissions to start a working 'virtual' desktop?
Technically it's a called a "windowstation". It should be already running. Documentation? mmm, a search on MSDN gives:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/base/window_stations.asp
as a starting point. Google et al have some hits. I'd read about it back in the NT 4.0 days and also had a primary
from the Softway Chief Scientist after he'd gotten to talk with the NT kernel guys (this is back in 1996 I think).
The problem usually boils down to PATH missing a path. The PATH in the Unix shell gets translated from Unix-speak
to Win32-speak when a Win32 process is run. Error messages about "can't find" usually come out on the GUI. I've had
it where the app will report to the command line that it find XXX.DLL and the GUI is reporting YYY.DLL is missing
(at the same time). Added the location of the directories these DLL's were in to PATH and then things were fine.
|
|
|
|
 New Messages |
 No New Messages |
 Hot Topic w/ New Messages |
 Hot Topic w/o New Messages |
|
 Locked w/ New Messages |
 Locked w/o New Messages |
|
 Post New Thread
Reply to Message
Post New Poll
Submit Vote
Delete My Own Post
Delete My Own Thread
Rate Posts |
|
|
|
Printable Version
