> From what I vaguely remember it is Windows that closes those streams for
> GUI executables,
Something like that, yes, although they are not "closed" in the sense
that they would first be open ("inherited" in the Unix sense); they
are never open in the first place in GUI executables, unless
explicitly redirected when creating the process (which the shell,
cmd.exe, does when you redirect input/out from/to a file/pipe). (HEre
I talk about the underlying Win32 file handles; the C library's file
descriptors, and the corresponding C++ streams probably *are* "open",
even if connected to invalid file handles.)
> In Windows builds there used to be
> a solver/$INPATH/bin/guistd.com or some such that if copied to the path
> of soffice.exe and renamed to soffice.com and invoked instead preserved
> stdout/stderr streams. Maybe it's still built.
Not for soffice, there we just have soffice.exe and soffice.bin. But
for unopkg we deliver three different exectuables: unopkg.com,
unopkg.exe and unopkg.bin, which start each others in that order, if I
understand correctly.
Now, if I understand the purpose of the outermost wrapper, the
guistdio == unopkg.com thing, that is probably not needed any more on
modern Windowses (XP or later) as it is possible for a process to
"attach" to the console (think controlling terminal in Unix terms) of
the parent process, and thus acquire the possibility to reopen its
stdin/out/err to the paren't process's console. Look for documentation
for AttachConsole(ATTACH_PARENT_PROCESS).
--tml
_______________________________________________
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
