For certain reasons, when a single user requests multiple instances of
the same soffice process to run in parallel, this is instead handled
internally by only one instance running and all other instances passing
their command lines over a pipe to that one instance, and then
terminating again. See desktop/source/app/officeipcthread.cxx:1.56
(SRC680m227).
1 The protocol for that pipe communication seems to be undocumented.
Reverse-engineering desktop/source/app/officeipcthread.cxx:1.56 gives
the following picture:
1.1 One soffice process can send to another soffice process three kinds
of messages:
1.1.1 The null-terminated ASCII byte sequence
"InternalIPC::TerminateThread".
1.1.2 The null-terminated ASCII byte sequence
"InternalIPC::ProcessingDone".
1.1.3 The sequence of command line arguments as reported by
osl_getCommandArg(0, ...), ...,
osl_getCommandArg(osl_getCommandArgCount() - 1, ...), in the following form:
1.1.3.1 If the sequence is empty, the null-terminated ASCII byte
sequence "-tofront".
1.1.3.2 Otherwise, for each argument in succession the following
encoding, finally followed by a null byte:
1.1.3.2.1 First, if the current argument does not start with a "-" and
is not directly preceded by an argument "-pt":
1.1.3.2.1.1 First, if the current argument starts with "file:" it is
translated into an internal URL via
com.sun.star.uri.ExternalUriReferenceTranslator.translateToInternal, or
left untranslated if that fails.
1.1.3.2.1.2 Then it is translated into an absolute internal URL via
some complicated GetURL_Impl (desktop/source/app/app.cxx:1.209).
1.1.3.2.2 Then the current argument is converted into a byte sequence
via ByteString(..., osl_getThreadTextEncoding()) and a trailing ASCII
"|" byte is added.
1.2 Some other process can send to an soffice process a "lookup
message" (see desktop/source/app/officeipcthread.cxx:1.56 l. 611)
consisting of a null byte.
2 Beside desktop/source/app/officeipcthread.cxx:1.56 there are further
places where processes send messages to an soffice process over such a pipe:
2.1 On Windows, when there is an appropriate perftune.ini, the
soffice.exe directly sends the command line, instead of starting the
soffice.bin that would then send the command line in
desktop/source/app/officeipcthread.cxx:1.56. The relevant code is in
desktop/win32/source/officeloader/officeloader.cxx:1.11 and it deviates
from 1.1.3 in the following ways:
2.1.1 In contrast to 1.1.3 it uses the command line arguments
CommandLineToArgvW(GetCommandLineW(), &argc)[1], ...,
CommandLineToArgvW(GetCommandLineW(), &argc)[argc - 1].
2.1.2 In contrast to 1.1.3.1 it sends a null byte if the sequence of
command line arguments is empty.
2.1.3 In contrast to 1.1.3.2.1 it does not translate applicable
arguments via
com.sun.star.uri.ExternalUriReferenceTranslator.translateToInternal or
GetURL_Impl.
2.1.4 In contrast to 1.1.3.2.2 it uses WideCharToMultiByte(CP_ACP, ...)
to convert arguments to byte sequences.
2.2 Reportedly, Novell uses a fast loader similar to 2.1 on Linux.
2.3 There are probably still other places (especially other
applications that send lookup messages, see 1.2).
3 Some observations:
3.1 Any relevant environment information (for Posix, for example
environment variables, current working directory, current root
directory) of the sending soffice process is not made available to the
receiving soffice process, so any interpretation of the command line
arguments of the sending process in the environment of the second
process can potentially fail.
3.1.1 Changing relative filepaths into absolute entities in 1.1.3.2.1.2
is obviously an attempt to work around such missing current working
directory information. However, it fails to take into account missing
current root directory information.
3.1.2 Translation to internal URLs in 1.1.3.2.1.1 and 1.1.3.2.1.2 is
obviously a (seemingly successful) attempt to work around such missing
locale information (LANG environment variable etc.).
3.2 -env command line arguments are passed from the sending to the
receiving process, but are probably not taken into account there.
4 I need to fix an issue caused by 2.1.3 (Sun-internal #b6527052#).
The main problem for that issue is that 2.1.3 fails to convert to
internal URLs. However,
desktop/win32/source/officeloader/officeloader.cxx:1.11 has no access to
com.sun.star.uri.ExternalUriReferenceTranslator.translateToInternal.
The easiest fix would be for
desktop/win32/source/officeloader/officeloader.cxx:1.11 to send URLs in
which non-ASCII characters are kept verbatim (instead of flattening them
into byte sequences and "%"-escaping them; see also
<http://www.openoffice.org/issues/show_bug.cgi?id=81275>), as those
(mildly invalid) URLs can equally be interpreted as external or internal
URLs. For that to work, part 1.1.3 of the protocol would need to be
changed, though.
5 Proposed replacement of protocol part 1.1.3:
5.1 The sequence of command line arguments as reported by
osl_getCommandArg(0, ...), ...,
osl_getCommandArg(osl_getCommandArgCount() - 1, ...) is transported as a
message, in the following form:
5.1.1 The ASCII byte sequence "InternalIPC::Arguments" as a prefix.
5.1.2 For each argument (if any) in succession the following encoding:
5.1.2.1 An ASCII "," byte.
5.1.2.2 First, if the current argument does not start with a "-" and is
not directly preceded by an argument "-pt":
5.1.2.2.1 First, if the current argument starts with "file:" it is
translated into an internal URL via
com.sun.star.uri.ExternalUriReferenceTranslator.translateToInternal, or
left untranslated if that fails.
5.1.2.2.2 Then it is translated into an absolute internal URL via some
complicated GetURL_Impl (desktop/source/app/app.cxx:1.209).
5.1.2.3 Then the current argument is converted into a byte sequence via
rtl::OUString::convertToString(..., RTL_TEXTENCODING_UTF8,
RTL_UNICODETOTEXT_FLAGS_UNDEFINED_ERROR |
RTL_UNICODETOTEXT_FLAGS_INVALID_ERROR), aborting the whole protocol upon
failure. The resulting byte sequence is transmitted, replacing each
occurrence of a null byte with an ASCII "\" byte followed by an ASCII
"0" byte, replacing each occurrence of an ASCII "," byte with an ASCII
"\" byte followed by an ASCII "," byte, and replacing each occurrence of
an ASCII "\" byte with an ASCII "\" byte followed by an ASCII "\" byte.
5.1.3 A trailing null byte.
6 Rationale for 5:
6.1 The new protocol allows for the safe transport of arbitrary Unicode
content, as required by 4.
6.2 It cleans up the protocol by removing the need for special handling
of empty argument sequences (1.1.3.1).
6.3 It cleans up the protocol so that all 1.1 messages start with a
"InternalIPC::" prefix.
Thoughts, anybody?
-Stephan
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
