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.
A good example how registry keys should be used for retrieving the path
of a runtime environment from the registry is Java.
- Assuming that OOo-wo-URE does know where the URE is located, how
can executables and DLLs in OOo-wo-URE access the DLLs in URE they
depend on? Extend the PATH? DLL hooks Hennes is currently working
on (would that scale)?
Extending the PATH will only work if OOo isn't implicitly linked
against URE or if OOo uses a wrapper that extends the path so OOo can
inherit it.
What do you mean with "implicitly linked?"
Using DLL hooks will scale as long as both OOo and URE are build with
DELAYLOAD DLL hoos.
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.
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.
- Are there any clever places to set the URE_BOOTSTRAP deployment
variable so that all executables in the "interface of OOo" are
guaranteed to have it set (for themselves and any other processes
they spawn, i.e., ideally as an environment variable)? The last
resort would be to make sure that next to each such executable named
foo there is a foo.ini that contains a definition for URE_BOOTSTRAP.
What Kay wrote is correct. Registry keys have a global context not
bound to an installation location. They may be bound to a version.
So, they are not useful to store information private to one specific
application installation, right?
If the application installation does does not come with a version number
exclusive for that installation - No.
If the information should be private to the installation it should
reside inside the installation. If the information is private to a
certain version of an application the registry is a good place.
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).
- Hennes
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
