Hennes Rohling wrote:
Stephan Bergmann wrote:
Hennes Rohling wrote:
Stephan Bergmann wrote:
[...]
I was talking from the consumer's point of view: If a consumer wants
to find out the location of the default URE in that consumer's
context, it will query HKEY_CLASSES_ROOT/Software/OpenOffice.org/URE.
That either internally redirects to HKEY_CURRENT_USER (in case the
consumer's context has a per-user URE override) or
HKEY_LOCAL_MACHINE. That's my understanding of Windows registry at
least.
The typical Windows "consumer" does not change registry keys directly
without some kind of front end ;-) But if he does he mostly know the
differences of the root keys. Furthermore HKEY_CLASSES_ROOT is just a
view not a real key. Reading from that key results in the effective data
for the current user but the results of writing to that key depends on
whether there are two similar keys in the two registry trees and whether
the user has access right to write to HKEY_LOCAL_MACHINE...things become
a little bit confusing.
Grr, it seems we are talking past each other here. With "consumer" I
meant some (software) instance that reads the registry key (in contrast
to a "producer" that writes the key). And the consumer sees the
HKEY_CLASSES_ROOT view and does not care whether the producer wrote to
HKEY_CURRENT_USER or HKEY_LOCAL_MACHINE.
[...]
Why do the URE DLLs need delayload hooks, too?
Because otherwise the DLL hooks won't scale. If f.e. sc680mi.dll from
OOo is linked against cppu3.dll which is linked against sal3.dll and
cppu3.dll and sal3.dll resides in an URE directory different from OOo's
directory then sc680mi.dll will find cppu3.dll but sal3.dll will not be
found as only sc680mi.dll comes with a delay load stub that may override
the runtime linker search path.
Ah, the DLLs that cppu3.dll depends on are not searched for next to
cppu3.dll in the default case where cppu3.dll does not have delayload hooks?
What I meant with "implicit" was using osl_loadModule or LoadLibrary.
Otherwise you will always need some kind of stub or wrapper because you
can't get rid of the console on windows OS when using some kind of
script (BAT, CMD) to set the PATH.
Not sure I get you here. The following would work, right? soffice.exe
does not link against any URE DLLs and executes soffice.bin with a PATH
that is extended with the URE bin directory. And similar for all other
top-level executables in the OOo-wo-URE tree. (Today soffice.exe links
against uwinapi.dll, which is also a---private---part of URE, so
something would need to be done about that.)
[...]
I don't exactly understand what the goal of the approach is. Assuming
there are two installations of the same application (I'm talking about
OOo) you might run into trouble beside the issue of finding the
installation private URE anyway. F.e. the pipe name used to pass
arguments to an already running office currently consist of
(version+user path+user id) but not the install path (All platforms, not
only Windows).
"user path" being the path of the OOo user installation? I would assume
that two different OOo installations would use different user
installations, so the pipe names would be different in such a scenario.
(My goal is to be able to have two almost identical OOo installations
on one machine, e.g., when working in parallel on two different CWS.)
-Stephan
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
