Hennes Rohling wrote:
Stephan Bergmann wrote:
[...]
- An installed URE already announces its location in the Windows
registry at HKEY_CLASSES_ROOT\Software\OpenOffice.org\URE. But, even
if all the code that needs to know this value can read it (e.g., we
introduce additional syntax so that the URE_BIN_DIR deployment
variable can be set to something like
"${registry:HKEY_CLASSES_ROOT/Software/OpenOffice.org/URE:Path}"), one
ugly problem would remain: It would not be easy at all to install two
different pairs of URE and OOo-wo-URE on the same machine (which is of
utmost importance at least for developers, and somewhat easily solved
in the Unix scenario above---all you have to do is adjust the one
symbolic link per installed URE/OOo-wo-URE pair).
HKEY_CLASSES_ROOT is wrong. It's just a merged view of
HKEY_CURRENT_USER\Software\Classes and HKEY_LOCAL_MACHINE\Software\Classes.
I guess HKEY_LOCAL_MACHINE is meant if OOo was deployed for all users.
Otherwise HKEY_CURRENT_USER is the right base key.
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.
- 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?
- 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?
-Stephan
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
