Hi all!
in short: I consider it at least strange, that a deployed
headless application on MS Windows opens either a console
window or does no logging to console at all, depending on
the type of vm used to start it. This is on 7.4d.
The company I work for deploys a set of applications, some
of them headful, others headless. Headless applications always
load the Headless parcel. While the logical step would be to
build all headless executables with vwntconsole.exe, we sometimes
use vwnt.exe or visual.exe. The latter do no console logging
via the external interface we use, all printed strings are
lost somewhere.
Using vwntconsole.exe has the effect, that a dos-shell like
window pops up, when double clicked. These windows have the
same annoying properties as other dos windows, e.g. they pause
the running process if the user selects some text in that
window with the mouse. For a server process this is unacceptable.
Also users tend to close the window, because they do not want
to see the output, which also ends the process, which is also
often undesireable.
This "window opening" feature of vwntconsole.exe seems to come
from the notion of "oh dear, no stdin and no stdout. quick
create some". Compared to unix this would be like double
clicking the "/bin/ls" from <insert favourite visual file
browser> and having an xterm opening up, showing the results.
If the standard I/O channels are dead, I do not expect software
to create them by interacting with OS elements that are not
in their "scope".
I know about the command line option mentioned by vwconsole.exe
-console open a console for stdout/stderr
but we certainly do not provide it in the build process.
Am I missing something?
If vwntconsole.exe behaves this way, I vote for eliminating
this "open a window" feature. Also vwnt.exe should be able to
read from / write to standard I/O.
Regards
Jan
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc